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MEMORANDUM  FOR  ASSISTANT  SECRETARY  OF  THE  ARMY  (INSTALLATIONS, 

LOGISTICS,  AND  ENVIRONMENT) 

ASSISTANT  SECRETARY  OF  THE  NAVY  (RESEARCH, 
DEVELOPMENT,  AND  ACQUISITION) 

ASSISTANT  SECRETARY  OF  THE  AIR  FORCE 
(ACQUISITION) 

DIRECTOR,  DEFENSE  LOGISTICS  AGENCY 
DIRECTOR  FOR  LOGISTICS  (J-4) ,  JOINT  STAFF 
DEPUTY  COMMANDER-IN-CHIEF,  U.S.  TRANSPORTATION 
COMMAND 

SUBJECT:  Department  of  Defense  (DoD)  InTransit  Visibility  (DITV) 

Integration  Plan 


I  am  pleased  to  forward  the  attached  DITV  Integration  Plan  for 
your  information  and  action.  The  U.S.  Transportation  Command 
(USTRANSCOM)  developed  the  plan  at  the  direction  of  my  office  and 
in  coordination  with  the  DoD  Components.  This  plan  represents  a 
joint,  high-level  statement  of  requirements  and  functional  design 
for  achieving  an  ITV  capability  for  the  Department  and  is 
consistent  with  the  Total  Asset  Visibility  (TAV)  Plan  currently 
being  developed  by  the  TAV  Joint  Task  Force.  The  DITV  Integration 
Plan  provides  an  early  opportunity  to  begin  implementing  tasks 
necessary  for  achieving  the  ITV  segment  of  TAV. 

It  is  important  that  all  DoD  Components  work  in  concert  and 
allocate  the  necessary  resources  to  help  resolve  the  asset 
visibility  problems  that  have  plagued  us  in  the  past.  The  DITV 
Integration  Plan  provides  the  framework  to  support  us  in  that 
endeavor.  Along  with  a  statement  of  requirements  and  functional 
design,  the  DITV  Integration  Plan  details  ITV  operating  concepts 
for  each  segment  of  the  transportation  pipeline;  summarizes  ongoing 
ITV-related  initiatives  and  systems  development  efforts;  identifies 
major  activities  critical  to  achieving  a  comprehensive  ITV 
capability;  and  proposes  implementation  priorities  and  responsible 
organizations  for  achieving  a  worldwide  ITV  capability. 

I  fully  support  the  DITV  Integration  Plan's  recommendations 
and  solicit  your  help  in  completing  those  actions  under  your 
purview.  As  the  lead  agency  for  ITV,  USTRANSCOM  will  coordinate 
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DoD  efforts  in  implementing  the  actions  identified  in  the  DITV 
Integration  Plan.  Your  full  cooperation  in  assisting  USTRANSCOM  in 
this  critical  undertaking  is  great^LYK^PP^eciated. 


James  R.  Klugh 
Deputy  Under  Secretary 
of  Defense  (Logistics) 


Attachment 


FOREWORD 


The  United  States  Transportation  Command,  as  the  designated 
Department  of  Defense  (DOD)  focal  point  for  In-Transit  Visibility 
(ITV),  declared  1994  as  "The  Year  of  ITV."  As  an  outgrowth  of 
this  declaration,  USTRANSCOM  embarked  on  an  aggressive  program  of 
study  and  development.  The  resulting  ITV  integration  plan  is 
aimed  at  focusing  energy,  attention,  and  resources  toward 
obtaining  an  ITV  capability  for  DOD. 

Comprehensive  ITV  is  an  essential  element  of  the  DOD's 
warfighting  capability  and  the  supporting  logistics  operational 
processes.  The  two  principal  elements  of  this  capability  are: 

(1)  automation  at  shipment  sources  to  generate  accurate  data  and 
send  it  to  other  operational  nodes  to  support  follow-on  processes 
and  (2)  a  central  transportation  data  repository  to  support 
transportation  management  processes,  current  and  future 
operations  planning  processes,  reports  and  data  sharing,  and 
customer  inquiries. 

This  plan  identifies  high-level  requirements  for  ITV  and  the 
functional  design  for  an  integrated  ITV  capability.  It  is 
intended  to  be  a  living  document  that  will  be  supplemented  with 
more  detailed  action  plans  as  needed  to  remove  impediments  to 
timely  and  effective  information  exchange  between  transportation, 
operations,  and  command  and  control  nodes. 

This  plan  has  been  coordinated  with  the  Office  of  the  Secretary 
of  Defense,  the  Joint  Staff,  the  military  Services,  the  unified 
commands,  and  the  defense  agencies.  The  plan  is  consistent  with 
DOD's  Total  Asset  Visibility  objectives  of  improving  logistics 
support  to  customers  through  process  improvement  and  application 
of  state-of-the-art  technologies.  USTRANSCOM  is  the  primary 
agency  to  coordinate  DOD-wide  efforts  to  implement  this  plan  and 
ensure  DOD  gains  a  comprehensive  ITV  capability.  However,  the 
continuing  involvement  of  all  DOD  components  is  required  to 
identify  system  and  procedural  impediments  to  effective 
operations  and  ITV. 


Comments  and  suggestions  should  be  forwarded  to: 
USTRANSC0M/TCJ4-LT,  508  Scott  Dr,  Scott  AFB  JI^2225-5357 
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Defense  Intransit  Visibility  Integration  Plan 


Executive  Summary 


Background 

In  every  major  deplo5rment  during  the  20th  century,  the  Department  of  De¬ 
fense  (DoD)  has  been  plagued  by  a  lack  of  visibility  over  shipments  and  units  en¬ 
tering  a  theater  of  operations.  During  Desert  Shield/Storm,  more  than 
20,000  containers  of  military  materiel  (out  of  a  total  of  40,000)  entering  the  theater 
had  to  be  opened,  inventoried,  resealed,  and  then  reinserted  into  the  transporta¬ 
tion  system  simply  because  military  personnel  in  the  theater  did  not  know  their 
contents.  The  movement  of  troops  was  also  hampered  by  the  lack  of  visibility 
over  personnel  moving  into,  within,  and  out  of,  the  area  of  operations.  In  addi¬ 
tion,  60  percent  of  evacuated  patients  ended  up  at  the  wrong  destination.  The 
DoD  lacked  timely  movement  status  information  needed  to  divert  and  reconsti¬ 
tute  deploying  unit  and  non-unit  shipments.  Fortimately,  it  had  time  to  ensure 
that  all  deployed  units  received  their  necessary  combat  materiel  before  fighting 
began,  a  luxury  that  may  not  exist  in  future  deployments.  These  shortcomings  in 
logistics  operations  will  continue  to  exist  imtil  the  DoD  implements  a  compre¬ 
hensive  intransit  visibility  (ITV)  capability. 

This  plan  provides  the  functional  design  for  an  integrated  ITV  capability.  It 
presents  the  high-level  requirements  of  that  system,  ongoing  initiatives  that  have 
ITV  potential,  detailed  operating  concept  for  capturing  ITV  data,  procedural  and 
technical  issues  and  key  considerations,  and  an  implementation  schedule.  This 
plan  is  not  intended  to  provide  the  technical  architecture,  user  interface  require¬ 
ments,  detailed  data  requirements,  or  economic  analysis  for  the  fully  integrated 
system.  The  U.S.  Transportation  Command  (USTRANSCOM)  wiU  use  the  plan 
to  oversee  the  progress  of  Defense  transportation  initiatives,  including  func¬ 
tional  process  improvements,  system  enhancements  and  interfaces,  and  data 
quality.  The  Global  Transportation  Network  (GTN)  Program  Management  Office 
will  also  use  it  to  prioritize  and  schedule  its  development  efforts.  The  Office  of 
the  Secretary  of  Defense  (OSD)  will  rely  on  the  plan  to  establish  policies  and  pro¬ 
cedures  and  to  identify  and  support  fimding  and  resource  requirements.  Finally, 
this  plan  provides  the  Military  Services,  Defense  agencies,  USTRANSCOM  and 
its  transportation  component  commands,  and  the  Joint  Staff,  with  a  singular 
course  of  action  for  developing  an  integrated  ITV  capability. 

Intransit  visibility  is  the  ability  to  track  the  identity,  status,  and  location  of 
DoD  unit  and  non-unit  cargo  (excluding  bulk  petroleum,  oils,  and  lubricants) 


and  passengers;  medical  patients;  and  personal  property  from  origin  to  con¬ 
signee  or  destination  during  peace,  contingencies,  and  war.  However,  it  consti¬ 
tutes  only  a  portion  of  the  requirements  for  Total  Asset  Visibility  (TAV),  which 
also  includes  the  tracking  of  inprocess  assets  (being  procured  or  repaired)  and  in¬ 
storage  assets  (inventory  at  Defense  storage  locations). 

The  DoD  has  long  been  aware  of  the  value  of  ITV.  A  few  years  ago,  OSD  as¬ 
signed  USTRANSCOM  responsibility  for  developing  a  DoD-wide  ITV  capability. 
As  the  DoD  ITV  functional  proponent,  USTRANSCOM's  ITV  responsibility  be¬ 
gins  at  origin  and  ends  with  receipt  at  the  consignee  or  destination  designated  by 
the  Commanders  in  Chief  (CINCs),  Military  Services,  or  Defense  agencies.  As  an 
initial  response  to  that  tasking,  USTRANSCOM  developed  a  GTN  prototype  to 
provide  ITV  over  air  and  surface  shipments  moving  between  ports  of  embarka¬ 
tion  and  debarkation  (POEs  and  PODs).  USTRANSCOM  is  now  in  the  process  of 
expanding  the  ITV  module  of  GTN  to  encompass  movements  from  CONUS  ori¬ 
gins,  through  the  ports,  and  forward  to  theater  destinations.  The  GTN  is  also  the 
means  of  updating  the  Worldwide  Military  Command  and  Control  System 
(WWMCCS)  and  Joint  Operations  Planning  and  Execution  System  (JOPES)  with 
selected  transportation  movement  information.  Ultimately,  GTN  wiU  become  the 
integrated  transportation  module  of  Global  Command  and  Control  System 
(GCCS),  the  system  that  will  replace  WWMCCS  and  JOPES.  Eventually, 
USTRANSCOM  will  coordinate  with  other  Defense  activities  to  integrate  GTN 
with  other  logistics  systems  as  part  of  a  TAV  systems  architecture. 


TAV  Integration 

In  order  to  identify  the  required  TAV  systems  architecture  and  develop  a 
plan  for  its  implementation,  OSD  has  established  a  Joint  Task  Force  (JTF).  The 
ITV  requirements,  operating  concepts,  and  implementation  schedules  in  this  in¬ 
tegration  plan  are  consistent  with  the  efforts  of  the  JTF  to  develop  broader  oper¬ 
ating  concepts  for  a  greater  TAV  operating  environment.  In  areas  where  TAV 
and  ITV  overlap,  such  as  direct  vendor  delivery  shipments,  development  of  a 
theater  material  management  system,  and  implementation  of  automatic  identifi¬ 
cation  technology,  efforts  have  been  taken  to  ensure  that  the  proposed  ITV  oper¬ 
ating  concept  is  consistent  and  complimentary  with  TAV.  The  key  to  integrating 
TAV  and  ITV  is  the  development  of  a  single  interface  for  all  DoD  TAV  users. 
Such  an  interface  will  most  likely  be  accommodated  between  GTN  and  Defense 
Automatic  Addressing  System  (DAAS)/ Logistics  Information  Processing  Sys¬ 
tem.  When  fully  implemented,  GTN  will  become  the  intransit  portion  of  DoD's 
greater  TAV  system. 


Requirements 

At  the  highest  level,  DoD's  requirements  for  ITV  are  well  known.  At  a  mini¬ 
mum,  the  ITV  system  should  identify  the  contents  of  a  shipment  and  monitor  its 
location  as  it  moves  from  origin  to  destination.  It  should  also  enable  DoD 


Components  to  track  individual  requisitions,  items,  and  unit  movements;  recon¬ 
stitute  shipments;  and  divert  shipments  to  new  destinations.  To  satisfy  those  re¬ 
quirements,  a  link  needs  to  be  established  among  DoD's  maintenance,  material 
management,  and  command  and  control  systems.  The  system  must  also  have 
the  capability  to  operate  from  source  to  destination  (including  redeployments 
and  retrograde  shipments);  be  available  during  peace,  contingencies,  and  war; 
and  support  both  the  operatioiis  and  logistics  communities.  Finally,  it  must  meet 
these  requirements  for  all  Defense  materiel,  passenger,  and  patient  movements. 
This  list  is  hardly  inclusive  —  there  are  many  other  detailed  data,  system  inter¬ 
face,  and  procedural  requirements  —  that  are  presented  as  part  of  the  ITV  oper¬ 
ating  concept. 


Functional  Concepts  and  Related  Actions 

The  plan  divides  ITV  into  two  major  components  —  cargo  and  personnel.  It 
further  divides  cargo  into  unit,  non-unit,  personal  property,  and  redeployment 
cind  retrograde  subcomponents;  and  personnel  into  xmit,  non-unit,  medical  pa¬ 
tients,  and  redeployment  subcomponents.  A  brief  description  of  the  operating 
concept  and  implementation  schedule  for  each  ITV  subcomponent  follows.  AU 
schedules  are  contingent  upon  the  award  of  the  GTN  contract  planned  for  early 
1995. 

At  the  heart  of  DoD's  ITV  operating  concept  is  the  ITV  module  of  GTN.  It 
will  be  DoD's  comprehensive  data  base  of  intransit  shipment  information,  in¬ 
cluding  all  military,  government,  and  vendor  documented  shipments.  It  will 
also  capture  shipment  status,  booking  information,  passenger  reservations  and 
manifests,  personal  property,  medical  patients,  and  vessel  and  aircraft  schedul¬ 
ing  data.  This  integration  plan  identifies  the  operating  concepts  and  implemen¬ 
tation  schedules  for  gathering  that  information.  It  does  not  identify  the  system 
interface  requirements  and  operating  concepts  for  accommodating  ITV  and  TAV 
user  inquiries.  The  user  interface  requirements  for  command  and  control  will  be 
identified  when  GCCS  is  developed.  As  the  JTF  finalizes  DoD's  TAV  require¬ 
ments,  the  optimal  technical  configurations  and  operating  concepts  for  facditat- 
mg  all  other  user  inquiry  requirements  will  be  identified. 


Cargo  —  Unit  Movements 

Unit  cargo  includes  all  unit  equipment,  accompanying  supplies.  Marine 
Corps  Maritime  Prepositioned  Forces;  Army  unit  equipment  aboard  pre¬ 
positioned  afloat  ships;  and  Prepositioning  of  Materiel  Configured  to  Unit  Sets 
(POMCUS)  stocks.  In  order  to  provide  the  status  and  location  of  all  unit  move¬ 
ments  from  origin  to  destination,  GTN  should  be  able  to  track  commercial  and 
organic  shipments  of  unit  cargo  by  the  shipment  identification  number;  transpor¬ 
tation  control  number  (TCN);  unit  line  number  (ULN);  and  unit  identification 
code  (UIC).  (The  ULN  and  UIC  are  embedded  in  the  TCN.)  For  government  and 
commercial  bills  of  lading,  GBLs  and  CBLs  respectively,  the  TCN  is  provided  in 
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the  shipment  description.  Widespread  use  of  these  codes  and  numbers  would 
enable  users  to  maintain  ITV  of  unit  equipment  on  a  line-item  basis. 

The  ITV  operating  concept  for  unit  movements  calls  for  GTN  to  receive  unit 
movement  data  from  source  systems,  POE  and  POD  systems,  and  a  joint  theater 
transportation  system  (see  Figure  1).  The  source  systems  include  the  Military 
Services'  Transportation  Coordinator's  Automated  Information  for  Movement 
Systems  (TC  AIMSs).  The  port  systems  include  the  Terminal  Management  Sys¬ 
tem  (TERMS),  which  will  soon  be  replaced  by  the  Worldwide  Port  System 
(WPS),  for  surface  movements,  and  the  Consolidated  Aerial  Port  System  II 
(CAPS  II)  for  air  movements.  The  theater  transportation  system  has  not  yet  been 
developed,  but  could  build  upon  the  partial  capability  already  available  through 
TC  AIMS;  the  Standard  Theater  Army  Command  and  Control  System  (STACCS), 
which  tracks  Army  unit  movements;  and  the  Department  of  the  Army  Move¬ 
ment  Management  System  —  Redesign  (DAMMS-R),  which  forecasts  and  tracks 
inter-theater  cargo  and  containers. 

When  a  unit  movement  occurs,  TC  AIMS  would  transmit  shipment  informa¬ 
tion  to  CTN  and  the  appropriate  POE  system.  If  the  unit  cargo  movement  is 
documented  using  a  CBL,  the  data  would  be  transmitted  from  TC  AIMS  to  the 
CONUS  Freight  Management  (CFM)  system,  which  would  then  update  GTN. 
When  the  unit  movement  reaches  the  POE,  the  port  system  would  provide  GTN 
with  port  arrival  and  departure  data.  The  POD  would  send  similar  updates  to 
GTN  and  the  theater  transportation  system.  Finally,  GTN  would  receive  destina¬ 
tion  arrival  data  from  the  theater  system.  Untiil  the  theater  system  is  developed, 
however,  GTN  should  consider  interfacing  with  STACCS  for  Army  unit  move¬ 
ments. 

While  the  DoD  has  made  much  progress  in  implementing  portions  of  this 
concept,  it  needs  to  resolve  two  key  issues  before  ITV  is  possible.  First,  the  DoD 
needs  to  develop  a  theater  transportation  system  that  would  provide  GTN  with 
ITV  information  from  any  theater.  Second,  it  needs  to  develop  interfaces  between 
GTN  and  TC  AIMS,  CFM,  the  air  and  siuface  port  systems,  STACCS,  and  joint 
theater  system.  Full  implementation  of  this  ITV  subcomponent  is  contingent 
upon  the  development  of  a  theater  system,  which  is  scheduled  for 
December  1997,  and  the  subsequent  system  interfaces  with  that  system  by 
June  1999.  However,  DoD  could  achieve  some  interim  ITV  through  system  inter¬ 
faces  between  GTN  and  TC  AIMS,  and  GTN  and  STACCS,  by  June  1996  and 
September  1997,  respectively. 


vr 


CONUS 

origin 


POE 


WPS 
CAPS  II 
TC  AIMS 


Theater 
destination 


POD 


Note: 


STACCS 
DAMMS-R 
TC  AIMS 

All  arrows  signify  MILSTAMP  data  transactions  unless  otherwise  annotated. 


WPS 
CAPS  II 
TC  AIMS 


Figure  1. 

Unit  Cargo 

Cargo  —  Non-Unit  Movements 

Non-unit  cargo  includes  all  sustainment  materiel  (except  the  supplies  and 
equipment  accompanying  a  tmit  during  deployment)  in  CONUS,  pre-positioned 
overseas,  or  afloat.  GTN  should  be  capable  of  tracking  all  non-unit  cargo  ship¬ 
ments,  from  origin  to  its  CONUS  or  theater  destination,  by  shipment  identifica¬ 
tion  number,  TCN,  national  stock  number  (NSN),  and  requisition  number. 
Non-unit  cargo  is  documented  using  transportation  control  and  movement 
documents  (TCMDs),  GBLs,  and  CBLs.  That  documentation  also  includes  a  vari¬ 
ety  of  non-standard  mail  and  vendor  shipment  information  and  commercial 
carrier-status  information. 

Lessons  learned  during  Desert  Shield/Storm  show  that  the  greatest  benefits 
from  implementing  ITV  are  in  the  non-unit  cargo  area.  However,  non-unit  cargo 
also  poses  some  of  the  greatest  implementation  challenges.  For  example,  more 
than  1,000  CONUS  installation  transportation  offices,  supported  by  at  least 
11  application  systems,  initiate  millions  of  non-unit  cargo  shipments  every  year 
using  all  modes  of  transportation.  In  addition,  about  one-third  of  aU  non-unit 
shipments  originate  with  commercial  vendors.  Finally,  all  shipments,  whether 
from  a  DoD  or  commercial  source,  are  documented  using  a  variety  of  standard 
and  non-standard  formats. 
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Fortunately,  the  DoD  has  long  recognized  these  complexities  and  is  imple¬ 
menting  a  number  of  new  programs  to  improve  current  business  operations.  The 
GTN  Version  2  prototype  currently  captures  non-unit  cargo  data  from  CAPS  II 
and  TERMS.  In  January  1994,  the  Military  Traffic  Management  Command 
(MTMC)  implemented  electronic  data  interchange  (EDI)  techniques  for  receiving 
CBL  data  m  the  CFM  system  from  a  few  Defense  shippers.  MTMC  plans  to  inter¬ 
face  CFM  with  CTN,  along  with  expanding  its  CBL  program  to  include  more 
than  600  Defense  transportation  offices,  by  March  1997. 

However,  these  new  systems  constitute  only  a  part  of  a  comprehensive  non¬ 
unit  cargo  ITV  operating  concept.  That  concept  calls  for  CTN  to  receive  transpor¬ 
tation  information  from  source  systems  (through  CFM),  POE  and  POD  systems, 
and  the  theater  transportation  system;  and  requisition  and  NSN  data  from  DAAS 
(see  Figure  2).  The  source  systems  include  the  Military  Service  legacy  depot  sys¬ 
tems;  Defense  Logistics  Agency's  (DLA's)  new  Distribution  Standard  System 
(DSS),  and  Transportation  Automated  Management  System  (TRAMS);  systems 
supporting  the  Military  Services'  installation  transportation  offices;  and  all  com¬ 
mercial  vendor  systems.  The  port  systems  include  WPS  for  sruface  movements 
and  CAPS  II  for  air  movements.  The  theater  system  remains  to  be  developed. 
Until  that  system  is  developed,  CTN  should  interface  with  TC  AIMS  or  the 
DAMMS-R  systems  in  order  to  provide  interim  capability  by  Jtme  1996  and 
March  1997,  respectively. 

When  a  non-unit  shipment  occurs,  the  CONUS  source  system  would 
transmit  shipment  information  to  the  appropriate  aerial  or  surface  port, 
consolidation/containerization  point,  or  consignee.  If  the  shipment  is  docu¬ 
mented  using  a  CBL  or  CBL,  the  data  would  be  transmitted  to  the  CFM  system, 
which  then  updates  CTN.  The  Defense  Transportation  Tracking  System  (DTTS) 
would  forward  location  data  on  shipments  tracked  via  satellite  to  CTN.  The  POE 
systems  would  provide  GTN  with  three  ITV  messages  for  every  shipment:  ex¬ 
pected  shipment  arrival  information  (enhanced  MILSTAMP  data);  port  arrival 
information;  and  port  departure  information.  The  POD  systems  would  then  pro¬ 
vide  port  arrival  and  departure  information  to  both  GTN  and  the  theater  trans¬ 
portation  system.  Finally,  GTN  would  receive  destination  arrival  data  from  the 
theater  system. 

However,  before  DoD  can  implement  this  operating  concept,  it  needs  to  re¬ 
solve  four  issues.  First,  it  needs  to  ensure  the  availability,  quality,  and  timeliness 
of  MILSTAMP,  CBL,  CBL,  vendor,  mad,  and  shipment  status  data  from  commer¬ 
cial  carriers.  Second,  it  needs  to  develop  a  theater  transportation  system  capable 
of  providing  GTN  with  ITV  data  from  any  theater.  Third,  it  needs  to  expand 
DTTS  to  use  satellite  tracking  for  other  modes  of  transportation  and  commodi¬ 
ties,  and  for  OCONUS  shipments.  Finally,  it  needs  to  develop  GTN  interfaces 
with  CFM,  DTTS,  air  and  surface  port  systems,  DAMMS-R,  and  the  theater  sys¬ 
tem.  In  addition,  the  Joint  Transportation  CIM  (Corporate  Information  Manage¬ 
ment)  Center  (JTCC)  has  developed  a  transportation  migration  strategy  to  reduce 
the  number  of  Defense  systems  that  provide  source  data. 
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Figure  2. 

Non-Unit  Cargo  Operating  Concept 


The  schedule  for  implementing  this  ITV  operating  concept  for  non-tmit 
cargo  movements  is  dependent  upon  the  development  of  a  theater  transportation 
system,  which  is  scheduled  to  occur  by  December  1997  and  the  subsequent  inter¬ 
faces  of  various  transportation  systems  with  that  system  by  June  1999.  However, 
DoD  could  achieve  an  interim  capability  through  system  interfaces  between  GTN 
and  the  CFM  system  and  DAMMS-R  by  March  1997. 


Cargo  —  Personal  Property 

Personal  property  cargo  includes  household  goods,  tmaccompanied  bag¬ 
gage,  privately  owned  vehicles,  and  mobile  homes  belonging  to  military  mem¬ 
bers  and  civilian  employees  of  the  DoD  and  U.S.  Coast  Guard.  While  the 
personal  nature  of  this  cargo  mandates  close  attention  to  service  quality,  an  ITV 
capability  would  add  little  to  the  DoD's  ability  to  deploy  and  sustain  its  forces 
during  war  or  contingencies.  Although  the  personal  property  community's 
views  vary,  the  existing  visibility  appears  sufficient  imder  most  circumstances. 
Therefore,  funding  and  development  efforts  for  ITV  are  better  directed  at  higher 
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priority  commodities,  particularly  those  that  corrtribute  directly  to  force  deploy¬ 
ment  and  sustainment. 

Nonetheless,  the  DoD  can  still  increase  its  visibility  over  selected  personal 
property  shipments  relatively  easily  and  inexpensively  by  requiring  carriers  to 
provide  shipment  status  messages  using  EDI  techniques.  Those  status  messages 
should  be  provided  at  the  request  of  a  personal  property  shipping  office  when  a 
shipment's  ocean  transit  begins  and  ends,  and  when  the  shipment  has  not  been 
delivered  by  the  required  delivery  date.  The  DoD  could  implement  this  capabil¬ 
ity  by  June  1996. 


Cargo  —  Redeplo5mient  and  Retrograde 

A  theater  commander's  responsibility  for  the  movement  of  cargo  entering 
the  theater  does  not  end  when  the  cargo  arrives  at  its  destination.  Many  items, 
including  both  unit  and  non-unit  supplies  and  equipment,  are  subsequently  re¬ 
shipped  from  the  theater  to  CONUS  or  to  another  theater.  Theater  commanders 
retain  responsibility  for  the  movement  of  all  cargo  from  a  theater  point  of  origin 
through  arrival  at  a  theater  POE.  The  DoD  refers  to  materiel  leaving  a  theater  lo¬ 
cation  boimd  for  another  theater  as  redeployment  cargo  and  materiel  bound  for 
CONUS  as  retrograde  cargo. 

While  the  DoD  has  a  substantial  investment  in  a  CONUS  infrastructure  for 
deploying  unit  and  non-unit  cargo,  it  lacks  a  similar  infrastructure  for  redeploy¬ 
ment  and  retrograde  cargo.  Again,  the  lessons  learned  from  Desert  Shield/ Storm 
clearly  indicate  the  need  for  effective  redeployment  systems  in  overseas  theaters. 
Numerous  problems  arose  in  the  documentation  and  subsequent  redeployment 
of  unit  and  non-tmit  cargo  from  Europe  to  Saudi  Arabia  because  of  the  absence 
of  systems  in  Europe  to  generate  documentation  and  to  track  cargo  movements. 
Cvurent  doctrine  requires  flexibility  and  rapid  response  to  and  from  any  poten¬ 
tial  theater,  which  calls  for  the  development  of  a  single  theater  system  that  satis¬ 
fies  Joint  Staff,  Military  Service,  and  Defense  agency  requirements,  and  provides 
capabilities  similar  to  CONUS  deployment  systems. 

The  operating  concept  for  retrograde  and  redeployment  cargo  is  shown  in 
Figure  3.  The  proposed  theater  transportation  system  would  produce  standard 
shipment  information  documentation,  including  TCNs  for  unit  and  non-unit 
cargo.  It  would  have  the  capability  to  exchange  shipment  information  with  GTN, 
the  theater  POE  system,  and  in-theater  organic  and  foreign  commercial  carriers. 
Upon  arrival  of  the  redeploying  or  retrograde  cargo  at  the  POE,  the  port  system 
would  update  the  movement  information  and  pass  it  to  GTN.  Despite  the  logical 
simplicity  of  this  concept,  the  essential  theater  transportation  system  needs  to  be 
developed.  Key  milestones  include  development  of  the  theater  system  by 
December  1997;  the  completion  of  subsequent  interfaces  by  Jtme  1999;  and  in¬ 
terim  GTN  interfaces  with  TC  AIMS  by  June  1996,  and  DAMMS-R  by 
March  1997,  STACCS  by  September  1997  for  unit  redeployments. 
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Figure  3. 

Redeployment  and  Retrograde  Cargo 


Personnel  —  Unit  Movements 

Unit  personnel  include  all  civilian  and  military  passengers  directly  attached 
to  a  deploying  unit.  Modem  commercial  communications  and  live  media  cover¬ 
age  of  troop  movements  have  placed  additional  demands  upon  the  DoD  to 
maintain  visibility  of  personnel  moving  from  origin  to  a  theater  destination  via 
air  or  surface  transport.  As  a  consequence,  item-level  detail,  such  as  the  passen¬ 
ger's  name,  social  security  number,  service  specialty  code,  ULN,  ultimate  desti¬ 
nation,  and  intransit  location,  must  be  readily  accessible. 

To  ensure  the  availability  of  this  information,  the  ITV  operating  concept  for 
unit  personnel  includes  the  electronic  transmission  of  standard  passenger  mani¬ 
fests  from  CAPS  II  and  the  Military  Services'  TC  AIMSs  (see  Figure  4).  Those  sys¬ 
tems,  which  are  located  at  bases  and  ports  throughout  the  world,  would  transmit 
data  to  GTN  through  a  communications  gateway.  For  personnel  movements 
manifested  using  TC  AIMS,  the  origin  would  provide  the  port  system  (WPS  for 
surface  movements  and  CAPS  II  for  air  movements)  with  advance  manifest  in¬ 
formation.  Those  systems,  in  turn,  would  update  GTN  with  vessel  or  aircraft  de¬ 
parture  information  from  the  POE.  At  the  POD,  either  WPS  or  CAPS  11  would 
update  GTN  and  the  TC  AIMS  theater  module  with  vessel  or  aircraft  arrival  in¬ 
formation.  Finally,  TC  AIMS  would  update  GTN  when  the  unit  reaches  its  de¬ 
ployment  location. 
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Note:  All  unlabeled  arrows  indicate  manifest  data  flow.  PRAMS  =  Passenger  Reservation  and  Manifesting 
System;  SAIMD  =  standard  automated  input  media  device. 


Figure  4. 

Unit  Personnel  —  Operating  Concept 


The  DoD  has  some  ITV  of  unit  personnel  movements.  Interfaces  between 
GTN  and  CAPS  II,  and  the  Air  Mobility  Command's  Passenger  Reservation  and 
Manifesting  System  (PRAMS)  and  Clobal  Decision  Support  System  (CDSS)  al¬ 
ready  exist.  Those  interfaces  enable  CTN  to  track  deploying  unit  personnel  from 
POE  to  POD.  In  order  to  expand  this  capability  to  track  unit  personnel  from  ori¬ 
gin  to  final  destination,  DoD  needs  to  accomplish  two  major  activities.  First,  it 
needs  to  develop  a  standard  data  element  passenger  manifesting  format  and  a 
standard  automated  input  media  device  (SAIMD),  such  as  the  Soldier  Readiness 
Card.  Second,  it  needs  to  develop  system  interfaces  between  the  Military  Serv¬ 
ices'  TC  AIMS  (unless  they  migrate  to  a  single  system),  and  among  TC  AIMS, 
WPS,  and  CAPS  II.  The  planned  implementation  for  these  capabilities  depend 
upon  the  development  of  a  theater  transportation  system,  which  is  scheduled  to 
occur  by  December  1997,  and  the  subsequent  interfaces  of  various  transportation 
and  personnel  systems  with  that  system  (Jime  1999).  However,  DoD  should 
achieve  additional  interim  capability  through  a  CTN  and  TC  AIMS  interface  by 
June  1996. 

—  Non-Unit  Movements 

A  large  number  of  temporary  duty  and  permanent  change-of-station  person¬ 
nel,  medical  attendants,  and  filler  and  replacement  personnel  move  daily 
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through  military  and  commercial  transportation  systems.  The  DoD  needs  the 
capability  to  track  the  identity,  location,  and  movement  schedules  of  those  per¬ 
sonnel  to  ensure  that  field  units  and  naval  combatants  are  rapidly  brought  up  to 
strength  during  crisis  operations  and  war.  (A  Navy  ship's  early  sailing,  for  exam¬ 
ple,  could  require  diverting  inboxmd  crew  members  to  the  ship's  next  port  of 
call.)  The  tracking  of  these  types  of  personnel  presents  a  unique  challenge  to  the 
transportation  community  because  many  travel  individually  on  commercial  car¬ 
riers. 

The  nV  operating  concept  for  non-unit  personnel  calls  for  PRAMS  to  up¬ 
date  GTN  on  the  status  and  location  of  aU  DoD  passengers  (see  Figure  5).  That 
update  already  occurs  every  two  hours.  In  addition.  Air  Mobility  Command 
(AMC)  is  building  an  interface  between  PRAMS  and  commercial  airline  reserva¬ 
tion  systems  that  will  ultimately  provide  GTN  with  information  about  selected 
categories  of  DoD  personnel  traveling  on  commercial  airlines. 
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Figure  5. 

Non-Unit  Personnel  —  Operating  Concept 


In  contrast,  however,  the  Military  Services'  wartime  personnel  processing 
and  tracking  systems  do  not  interface  with  PRAMS,  which  results  in  personnel 
managers  manually  keying  reservation  requests  into  PRAMS  terminals.  Confir¬ 
mation  and  manifest  information  are  also  manually  keyed  into  various  personnel 
and  AMC  systems,  which  further  inhibits  the  exchange  of  information  and 
smooth  transition  from  peace  to  wartime  operations.  Until  the  Military  Services 
develop  the  capability  to  interface  with  PRAMS,  they  will  continue  to  obtain 


personnel  movement  information  directly  from  GTN.  The  DoD's  long-term  goal 
is  for  personnel  managers  to  directly  access  PRAMS  for  reservations,  confirma¬ 
tions,  and  information  on  persormel  movements.  The  Army  needs  to  work  with 
AMC  to  link  PRAMS  with  its  Replacement  Operations  Automation  Management 
System  (ROAMS).  That  electronic  linkage  could  eventually  serve  as  a  standard 
for  the  other  Military  Service  personnel  systems.  The  linkage  between  PRAMS 
and  ROAMS  is  scheduled  to  occur  by  June  1996,  while  AMC  expects  to  have 
PRAMS  linked  to  all  commercial  reservation  systems  by  June  1995. 


Personnel  —  Medical  Patients 

Another  key  subcomponent  of  personnel  movements  is  the  evacuation  of 
medical  patients  from  medical  treatment  facilities  (MTF),  whether  in  the  theater 
or  CONUS.  To  meet  this  requirement,  USTRANSCOM  is  developing 
TRANSCOM's  Regulating  and  Command  &  Control  Evacuation  System 
(TRAC2ES),  one  of  four  GTN  modules.  This  system  will  capture  patient  care  and 
movement  requirements  from  MTFs  worldwide,  select  the  destination  MTF,  and 
schedule  patients  for  evacuation.  It  will  contain  all  essential  patient  data,  along 
with  selected  transportation  data.  The  operating  concept  for  tracking  patients  is 
shown  in  Figure  6.  USTRANSCOM  expects  to  field  an  operational  prototype  of 
TRAC2ES  by  September  1997. 

Personnel  —  Redeployment 

Entire  units  and  individual  non-unit  personnel  are  periodically  reallocated, 
reassigned,  or  relocated  to  other  areas  of  operation  within  a  theater,  to  another 
theater,  or  back  to  CONUS.  Theater  commanders  and  the  personnel  community 
(gaining  and  losing  commands,  and  service  processing  centers)  are  required  to 
monitor  and  track  these  types  of  personnel  redeployments,  just  like  initial  de¬ 
ployments.  And  like  cargo,  personnel  redeployments  have  taken  on  added  im¬ 
portance  because  of  force  downsizing  and  the  potential  need  to  rapidly  redeploy 
those  forces  to  new  theaters  of  operations  or  return  them  to  permanent  bases  for 
reconstitution.  Therefore,  the  TTV  operating  concept  for  personnel  redeploy¬ 
ments  is  similar  to  that  for  personnel  deployments.  The  schedule  for  implement¬ 
ing  this  capability  also  depends  upon  the  development  of  a  theater 
transportation  system  by  December  1997  and  the  subsequent  system  interfaces 
by  Jime  1999.  However,  DoD  could  achieve  an  interim  capability  through  a  GTN 
and  TC  AIMS  interface  by  June  1996. 
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Note:  GPMRC  =  Global  Patient  Movement  Requirements  Center;  TPMRC  =  Theater  Patient  Movement 
Control  Center;  MARC  =  Multitechnology  Automated  Reader  Card. 


Figure  6. 

Medical  Patient  Operating  Concept 


Additional  Key  Actions 

The  DoD's  ITV  challenge  is  far  greater  than  completing  GTN  and  develop¬ 
ing  system  interfaces  to  capture  various  movement  data  for  every  functional 
area.  It  also  needs  to  accomplish  seven  major  activities: 

♦  Improve  data  quality  and  timeliness.  As  the  DoD's  lead  organization  for  trans¬ 
portation  matters,  USTRANSCOM  needs  to  develop  new  and  simplified 
transportation  policies,  procedures,  and  standards  that  are  geared  toward 
improving  the  quality  and  timeliness  of  transportation  data.  Those  policies, 
procedures,  and  standards,  which  should  be  incorporated  within  a  new  De¬ 
fense  transportation  regulation,  would  replace  a  myriad  of  existing  trans¬ 
portation  regulations.  In  developing  those  policies  and  procedures, 
USTRANSCOM  would  need  to  evaluate  and  reengineer  transportation  proc¬ 
esses  and  systems.  However,  simply  developing  new  policies  and  operating 
procedures  is  not  sufficient.  Defense  shippers  and  consignees  must  comply 
with  them.  One  way  to  ensure  compliance  is  to  standardize  education,  train¬ 
ing,  and  certification  of  Military  Service  and  Defense  agency  transportation 
agents.  Those  agents  would  be  accoimtable  for  the  quality  and  timeliness  of 
transportation  data.  In  addition  to  improving  the  quality  of  data  from  its 


own  shipping  activities,  the  DoD  must  also  improve  commercial  vendor  and 
carrier  compliance  to  DoD  regulations,  policies,  and  procedures  through 
new  contractual  terms. 


♦  Develop  a  joint  theater  transportation  system.  The  DoD  requires  a  joint  theater 
transportation  system  that  can  be  implemented  readily  in  any  part  of  the 
world.  This  system  should  be  capable  of  processing  shipment  i^ormation 
received  from  port  systems;  tracking  containers  and  pallets;  reading  auto¬ 
matic  identification  technology  (AIT)  and  other  devices;  interfacing  with 
GTN;  and  generating  documentation  for  deploying  and  redeploying  vmit 
cargo  and  personnel,  and  for  retrograde  cargo.  It  should  also  provide  infor¬ 
mation  for  intratheater  movements.  Finally,  it  should  be  capable  of  being  de¬ 
ployed  in  any  theater  and  developed  using  standard  data  elements. 


The  Deputy  Under  Secrefeiry  of  Defense  (Logistics),  DUSD(L),  in  coordina¬ 
tion  with  the  Joint  Staff,  should  designate  a  project  executive  agent  for  man¬ 
aging  the  development  of  the  theater  transportation  system.  In  accordance 
with  its  charter,  the  JTCC  would  support  the  project  executive  agent  by  es¬ 
tablishing  performance  objectives  for  the  theater  transportation  system;  con¬ 
ducting  process  improvements  applying  corporate  information  management 
methodologies;  coordinating  with  the  Joint  Staff,  Military  Services,  and  thea¬ 
ter  CINCs  to  establish  a  baseline  of  current  theater  systems  capabilities;  com¬ 
paring  existing  Military  Service  system  capabilities  against  the  performance 
objectives  to  identify  those  that  are  not  satisfied;  and  recommending  existing 
or  new  systems  to  serve  as  the  foimdation  for  the  theater  transportation  sys¬ 
tem.  Finally,  the  project  executive  agent  would  recommend  through  the 
Joint  Staff,  that  the  DUSD(L)  designate  either  USTRANSCOM  or  a  Military 
Service  as  the  acquisition  agency  to  develop  and  integrate  the  system. 


If  the  TAV  JTF  identifies  additional  requirements  for  the  theater  system  that 
expand  its  functionality  beyond  the  scope  of  transportation,  the  project  exec- 
tuve  agent  should  be  responsible  for  the  greater  theater  material  manage¬ 
ment  system,  including  the  transportation  module.  The  JTCC  will  be 
accovmtable  to  the  project  executive  agent  and  wiU  be  responsible  for  only 
the  transportation  module. 


♦  Enhance  communications  capacity.  The  DoD  needs  to  ensure  the  availability  of 
adequate  communications  capacity  to  support  ITV  requirements  in  peace 
and  war.  While  some  commercial  networks  could  augment  existing  DoD  ca¬ 
pabilities,  even  the  combination  of  Defense  and  commercial  networks  may 
be  inadequate  in  some  theaters.  USTRANSCOM  should  determine  the  com¬ 
munications  requirements  of  CTN  and  other  source  systems.  It  should  then 
work  with  theater  communications,  operations,  and  logistics  staffs  to  de¬ 
velop  a  strategy  for  prioritizing  and  allocating  assured  communications  ca¬ 
pacity.  The  DoD  also  needs  to  establish  an  EDI  value-added  network  in 
cooperation  with  commercial  carriers  and  vendors  to  provide  a  means  of 
capturing  shipment  and  location  status  data. 
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♦  Implement  a  system  migration  strategy.  The  CIM  program  will  ultimately  re¬ 
duce  the  number  of  Defense  transportation  systems,  which  will  reduce  the 
number  of  system  interfaces  required  to  support  ITV.  Thus  far,  only  three 
migration  systems  included  in  the  ITV  operating  concept  have  been 
selected  —  GTN,  DTTS,  and  WPS.  Any  reference  to  other  candidate  migra¬ 
tion  systems  is  not  intended  to  endorse  a  particular  system.  In  fact,  the  sys¬ 
tems  that  will  actually  support  the  operating  concepts  in  this  integration 
plan  are  entirely  dependent  on  the  JTCC  system  migration  process. 

♦  Ensure  systems  continuity.  The  CIM  program  is  also  reducing  the  funding  for 
the  maintenance  of  existing  transportation  systems  and  the  development  of 
new  systems.  Those  reductions  have  slowed  the  implementation  of  ITV  sys¬ 
tem  interfaces,  automated  identification  technology  integration  efforts,  pol¬ 
icy  and  procedural  enhancements,  and  EDI  capabilities  at  many  Defense 
transportation  activities.  OSD  should  require  Defense  transportation  activi¬ 
ties  to  include  those  capabilities  in  all  CIM  migration  systems.  In  some  ex¬ 
ceptional  cases,  OSD  should  also  support  the  Military  Services  and  DLA  to 
implement  critical  legacy  systems  changes. 

♦  Secure  funding  and  resources.  While  many  ITV  programs  have  already  been 
partially  or  completely  funded,  significant  funding  and  personnel  resources 
are  needed  to  field  the  comprehensive  program  outlined  in  this  integration 
plan.  In  accordance  with  OSD  guidance,  the  Military  Service  or  Defense 
agency  identified  as  the  lead  agent  for  each  portion  of  the  ITV  operating 
concept  is  responsible  for  identifying  and  budgeting  for  the  required  re¬ 
sources.  Those  resources  include  systems  development  and  enhancement, 
program  development  and  coordination,  organizational  restructuring,  and 
operating  costs.  For  system  development  and  enhancements,  OSD  will  sup¬ 
ply  additional  funding  guidance  as  the  JTCC  promulgates  the  transportation 
system  migration  strategy. 

♦  Implement  an  AIT  approach.  The  DoD  should  use  AIT  to  provide  supplemen¬ 
tal  ITV  data  whenever  adequate  communications  capacity  for  logistics  infor¬ 
mation  exchanges  may  not  be  available.  AIT  devices  could  provide  supply 
content  information  for  receipt  and  inventory  management,  and  facilitate 
the  collection  of  transportation  information  at  key  nodes  for  movement, 
staging,  and  diversion  decisions.  Supply  content  information  could  be  in¬ 
cluded  on  either  a  two-dimensiorral  bar  code,  laser  card,  or  radio  frequency 
(RF)  tag.  Transportation  information  could  be  included  on  an  RF  tag,  laser 
card,  or  two-dimensional  bar  codes  on  the  military  shipping  label  located  on 
the  outside  of  the  shipping  container  (either  a  seavan  or  mUvan).  The  spe- 
ciEic  technology—  whether  reflective  or  omni-directional  RF,  laser  card,  or 
two-dimensional  bar  code  —  depends  on  user  requirements  and  concept  of 
operations.  The  use  of  a  two-dimensional  bar  code,  laser  card,  and/ or  an  RF 
tag  would  provide  the  DoD  with  the  capability  to  capture  content  informa¬ 
tion  and  track  containers  using  existing  technologies.  USTRANSCOM  wiU 
propose  a  strategy  that  identifies  the  technology,  operating  concept,  and  im¬ 
plementation  plan  for  using  AIT  in  Defense  transportation.  This  strategy 


will  be  submitted  to  the  TAV  JTF  for  incorporation  into  the  overall  TAV 
strategy. 


Summary 


Many  of  the  DoD's  logistics  problems  during  Desert  Shield/Storm  would  be 
minimized  in  future  deplo5mients  if  USTRANSCOM  completes  the  development 
of  GTN  and  integrates  it  into  the  TAV  systems  architecture.  If  DoD  accomplishes 
the  actions  described  above,  operations  and  logistics  users  would  be  able  to  track 
shipments  at  the  requisition  and  item  level  from  source  to  destination.  They 
would  also  be  able  to  identify  intransit  asset  attrition,  divert  shipments,  track 
unit  deployments,  make  decisions  about  theater  infrastructure  and  support,  and 
prepare  theater  onward  movement  plans. 
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Chapter  1 


Introduction 


Background 

Defense  automated  systems  and  processes  do  not  provide  theater  command¬ 
ers  with  adequate  information  about  shipments  enroute.  This  shortage  of  infor¬ 
mation  was  particularly  acute  during  Desert  Shield/Storm.  More  than  20,000  of 
40,000  containers  entering  the  theater  had  to  be  stopped,  opened,  inventoried,  re¬ 
sealed,  and  reentered  into  the  transportation  system.  The  effects  of  those  actions 
were  twofold:  U.S.  forces  did  not  receive  critical  equipment  and  supplies  in  a 
timely  manner,  and  DoD  paid  an  estimated  $150  million  in  unnecessary  demur¬ 
rage  and  detention  fees  for  containers.^  Recent  military  exercises  have  confirmed 
that  a  comprehensive  intransit  visibility  (ITV)  program  is  key  to  diverting  tmits 
or  shipments  to  higher  priority  destinations  and  reconstituting  shipments  to  sat¬ 
isfy  the  immediate  needs  of  theater  commanders. 

Intransit  visibility  is  defined  as  the  ability  to  track  the  identity,  status,  and 
location  of  DoD  unit  and  non-unit  cargo  and  passengers,  patients,  and  personal 
property  from  origin  to  consignee  or  destination  during  peace,  contingencies, 
and  war.  In  times  of  peace,  ITV  becomes  an  important  fiscal  management  tool.  It 
reduces  the  cost  of  materiel  in  the  logistics  pipeline  and  decreases  inventory  and 
warehousing  costs.  During  contingencies  and  wartime,  ITV  has  the  potential  to 
significantly  affect  the  preparation  for  or  outcome  of  a  battle  or  war. 

The  DoD  has  designated  ITV  a  high-priority  initiative.  Subsequent  to  Desert 
Shield/ Storm,  the  Assistant  Secretary  of  Defense  (Production  and  Logistics)  de¬ 
veloped  a  Total  Asset  Visibility  (TAV)  Plan  that  "provides  for  the  phased  imple¬ 
mentation  of  the  key  policies,  procedures,  systems,  and  related  communications 
technologies  required  by  operators  and  logisticians  for  essential  visibility  of  DoD 
materiel  assets."  ITV  is  an  important  component  of  TAV. 

More  recently,  the  Deputy  Under  Secretary  of  Defense  (Logistics),  DUSD(L), 
and  U.S.  Transportation  Command  (USTRANSCOM)  have  jointly  worked  with 
the  Military  Services  and  Defense  agencies  to  develop  an  integration  plan  for 
ITV.  This  report  presents  that  plan.  The  plan  should  lead  to  determining  the 
fimctional  design  requirements  for  ITV,  developing  a  baseline  of  current  capa¬ 
bilities,  identifying  the  gaps  or  deficiencies  in  the  current  and  planned  capabili¬ 
ties,  formulating  an  operating  concept  for  capturing  ITV  data,  and  preparing 
implementation  plans  to  realize  that  operating  concept.  It  is  not  intended  to  pro¬ 
vide  either  the  technical  architecture,  user  interface  requirements,  or  the  detailed 
requirements  for  the  completed  system.  It  also  does  not  include  an  economic 

’  GAO  Report  NSIAD-92-258,  Operation  Desert  Storm,  Lack  of  Accountability  Over  Mate¬ 
rial  During  Redeployment,  May  1992. 
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analysis.  USTRANSCOM  will  use  the  plan  to  oversee  the  progress  of  Defense 
transportation  components  in  implementing  various  components  of  the  total  ITV 
system.  The  GTN  (Global  Transportation  Network)  Program  Management  Office 
(PMO)  will  use  the  plan  to  prioritize  and  schedule  its  development  efforts.  The 
Office  of  the  Secretary  of  Defense  (OSD)  will  rely  on  the  plan  to  establish  policies 
and  procedures  and  to  support  Military  Service  and  agency  funding  and  re¬ 
source  budgeting  efforts.  Finally,  the  plan  focuses  the  ITV  development  efforts  of 
the  Military  Services,  Defense  agencies,  USTRANSCOM  and  its  transportation 
component  commands,  and  the  Joint  Staff  on  a  singular  course  of  action. 


Overview  of  Current  Operations 

Figure  1-1  illustrates  a  generic  model  for  the  movement  of  DoD  unit  and 
non-unit  cargo  and  passengers  from  a  CONUS  origin  to  an  overseas  theater.  The 
model  divides  the  ITV  pipeline  into  three  major  segments:  CONUS,  intertheater, 
and  theater. 

The  CONUS  segment  involves  much  of  the  DoD's  supply  and  transportation 
network.  Typically,  a  requisition  is  sent  electronically  from  the  theater  to  the  De¬ 
fense  Automatic  Addressing  System  (DAAS),  which  then  routes  the  requisition 
to  the  inventory  control  point  (ICP)  responsible  for  managing  the  item  being  req¬ 
uisitioned.  After  processing  the  requisition,  the  ICP  creates  a  movement  require¬ 
ment  and  sends  it  to  one  of  approximately  30  maintenance  or  supply  depots  in 
CONUS  under  the  management  of  the  Defense  Logistics  Agency  (DLA).  The  de¬ 
pot  then  ships  the  item  to  either  a  container  consolidation  point  (CCP)  or  directly 
to  the  port  of  embarkation  (POE).  Alternatively,  the  ICP  may  authorize  a  com¬ 
mercial  vendor  to  supply  and  transport  the  item  directly  to  the  POE,  port  of  de¬ 
barkation  (POD),  or  final  destination. 

After  a  shipment  is  unloaded  at  the  POD,  it  is  sent  to  either  a  Military  Serv¬ 
ice  or  Defense  agency  supply  location,  a  military  unit,  or  a  theater  distribution 
point. 

Units  move  from  their  CONUS  locations  to  POEs  using  either  commercial  or 
organic  transportation  assets.  At  the  POE,  unit  equipment  enters  the  intertheater 
segment  of  the  ITV  pipeline.  USTRANSCOM  operates  two  types  of  POEs  —  air 
(operated  by  the  Air  Mobility  Command,  AMC);  and  surface  (operated  by  the 
Military  Traffic  Management  Command,  MTMC).  At  some  locations  the  Military 
Services  operate  their  own  POEs.  The  POE  operating  system  then  creates  a 
manifest  for  the  unit  equipment  and  coordinates  its  loading  on  an  AMC  cargo 
plane;  commercial  aircraft;  Military  Sealift  Command  (MSC)  ship;  or  commercial 
ship  for  delivery  to  the  POD.  After  being  unloaded  at  the  POD,  the  unit  equip¬ 
ment  is  then  moved  forward  to  its  destination. 
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Figure  1-1. 

Current  Operating  Environment 


Ongoing  Initiatives 

Within  the  past  few  years,  the  DoD  has  attempted  to  attain  ITV  through  a 
number  of  separate  initiatives.  Some  of  the  most  important  initiatives  are  de¬ 
scribed  in  more  detail  below. 


Global  Transportation  Network  ITV  Module 

The  USTRANSCOM  is  developing  the  GTN  as  a  command  and  control  in¬ 
formation  system  to  aid  in  satisfying  its  mission  of  global  transportation  man¬ 
agement.  Commanders  will  use  information  from  GTN  to  aid  in  the 
decision-making  process.  GTN  consists  of  four  subsystems  —  current 
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operations,  future  operations,  patient  movement,  and  ITV.  Thus  far, 
USTRANSCOM  has  focused  its  ITV  subsystem  development  efforts  on  tracking 
cargo  and  personnel  between  the  POE  and  POD. 

At  the  heart  of  DoD's  ITV  operating  concept  is  the  ITV  module  of  GTN.  It 
will  be  DoD's  comprehensive  data  base  of  intransit  shipment  information,  in¬ 
cluding  all  military,  government  bill  of  lading  (GBL),  commercial  bill  of  lading 
(CBL),  and  vendor  documented  shipments.  It  will  also  capture  shipment  status, 
booking  information,  passenger  reservations  and  manifests,  personal  property, 
medical  patients,  and  vessel  and  aircraft  scheduling  data.  This  integration  plan 
identifies  the  operating  concepts  and  implementation  schedules  for  gathering 
that  information.  It  does  not  identify  the  system  interface  requirements  and  op¬ 
erating  concepts  for  accommodating  ITV  and  TAV  user  inquiries.  The  user  inter¬ 
face  requirements  for  command  and  control  will  be  identified  when  the  Global 
Command  and  Control  System  (GCCS)  is  developed.  The  optimal  technical  con¬ 
figurations  and  operating  concepts  for  facilitating  all  other  user  inquiry  require¬ 
ments  will  be  identified  when  the  TAV  Joint  Task  Force  (JTF)  finalizes  DoD's 
TAV  requirements. 

As  a  result  of  the  complexities  of  GTN,  USTRANSCOM  is  developing  and 
deploying  the  system  in  phases.  In  1989,  USTRANSCOM  demonstrated  an  ITV 
"proof-of-concept"  prototype.  The  prototjrpe  focused  on  providing  answers  to  a 
small  number  of  ITV  queries  (principally  the  location  or  status  of  ammunition 
shipments,  containers,  and  passenger  movements)  by  pulling  "real-time"  ITV  in¬ 
formation  from  existing  data  bases. 

In  1990,  USTRANSCOM  fielded  Version  1  of  GTN.  Although  Version  1  re¬ 
lied  on  the  same  ITV  architecture  and  systems  developed  for  the  prototype,  it 
differed  in  two  areas:  it  used  leased  instead  of  dial-up  telephone  lines,  and  it 
used  a  cache  (temporary)  data  base  to  retain  query  information  for  24  hours. 

Since  both  the  protot5q3e  and  Version  1  systems  relied  on  pulling  data  from 
participating  systems,  they  were  highly  communications-intensive.  They  also 
processed  queries  individually  and  did  not  retain  the  results.  In  an  attempt  to  re¬ 
solve  those  problems,  USTRANSCOM  developed  GTN  Version  2,  which  uses  the 
participating  systems  to  "push"  information  to  a  centralized  data  base  as  part  of 
their  normal  protocols  and  processing  workloads.  This  architecture  permits  GTN 
to  support  a  much  larger  base  of  customers  without  significantly  increasing  the 
interactive  user-load  on  the  supporting  systems. 

Version  2.1,  which  USTRANSCOM  fielded  as  a  prototype  in  the  second 
quarter  of  FY93,  focuses  on  tracking  air  cargo  and  air  passengers  moving  from 
POE  to  POD.  Figure  1-2  shows  the  four  systems  that  provide  data  to  GTN  Ver¬ 
sion  2.1.  (See  Appendix  A  for  descriptions  of  these  and  other  systems  associated 
with  the  DoD's  ITV  initiative.)  Version  2.1  uses  MILSTRIP  AS  transactions  re¬ 
ceived  from  DA  AS  to  link  the  requisition  number;  national  stock  number  (NSN); 
and  transportation  control  number  (TCN).  The  TCN  is  then  linked  to  Advance 
Transportation  Control  and  Movement  Document  (ATCMD)  data  received  from 
AMC  port  activities  using  the  Headquarters  On-line  System  for  Transportation 
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(HOST)  network  of  systems.  Some  unit  movement  data  are  also  captured  from 
HOST.  For  passenger  movements,  GTN  receives  social  security  numbers  and 
names  from  the  Passenger  Reservation  and  Manifesting  System  (PRAMS), 
AMCs  passenger  reservation  system.  It  also  receives  aircraft  scheduling  infor¬ 
mation  from  AMCs  Global  Decision  Support  System  (GDSS). 


GTN  Version  2.1 
Integrated  data  base 

f  I 
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Figure  1-2. 

GTN  Version  2.1  —  Air  Interfaces 


GTN  Version  2.2,  fielded  in  January  1994,  adds  similar  capability  for  surface 
shipments.  Figxrre  1-3  shows  the  system  interfaces  required  for  this  version  of 
GTN.  Like  Version  2.1,  DAAS  provides  the  requisition  number,  NSN,  and  TCN 
data.  MTMC's  Worldwide  Port  System  (WPS),  Terminal  Management  System 
(TERMS),  and  Military  Export  Traffic  System  (l^TS  II)  provide  GTN  with  trans¬ 
portation  control  movement  document  (TCMD),  booking,  and  other  shipment  in¬ 
formation  for  surface  cargo  shipments  moving  between  POE  and  POD. 

GTN  Version  2.3  uses  an  improved  GDSS  interface  to  provide  enhanced  visi¬ 
bility  over  air  missions.  It  also  has  expanded  query  capability  for  air  and  surface 
missions. 

While  Version  2.3  of  GTN  provides  ITV  capability  only  between  POE  and 
POD,  it  establishes  the  foundation  for  expanding  ITV  capability  to  include 
CONUS  sources  for  both  cargo  and  passengers,  as  well  as  theater  movements  of 
cargo,  passengers,  and  patients.  USTRANSCOM  is  now  in  the  process  of  award¬ 
ing  a  contract  to  build  the  production  version  of  GTN.  That  version  will  support 
the  ITV  concept  of  operations  and  requirements  present  in  this  plan. 
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Figure  1-3. 

GTN  Version  2.2  —  Surface  Interfaces 


Global  Transportation  Network  TRAC2ES  Module 

The  USTRANSCOM  Surgeon  has  been  developing  a  patient  movement  sub¬ 
system,  TRANSCOM's  Regulating  and  Command  &  Control  Evacuation  System 
(TRAC2ES),  since  early  1993.  Patient  ITV  is  a  major  by-product  of  this  subsys¬ 
tem. 


TRAC2ES  was  initiated  to  assist  USTRANSCOM  with  its  intertheater  and 
CONUS  medical  regulating  and  aeromedical  evacuation  mission.  Since  then,  it 
has  been  expanded  to  include  the  intratheater  regulating  and  evacuation  mis¬ 
sion.  Mission  execution  remains  the  responsibility  of  the  supported  theater 
CINC. 

The  proof  of  concept  for  TRAC2ES  was  accomplished  in  January  1994.  The 
first  prototype  version  began  CONUS  testing  in  the  middle  of  1994,  with  an  op¬ 
erational  prototype  scheduled  for  fielding  in  the  third  quarter  of  1997. 


Defense  Transportation  EDI  Program 

When  fully  implemented,  the  Defense  transportation  electronic  data  inter¬ 
change  (DTEDI)  program  will  replace  many  routine  DoD  freight  and  personal 
property  documents  with  electronic  data  interchange  (EDI)  transactions.  The 


centerpiece  of  that  program  is  the  Defense  Finance  and  Accoimting 
Service  —  Indianapolis  Center's  (DFAS-IN's)  Defense  Transportation  Payment 
System  (DTRS).  Although  developed  principally  to  replace  an  outdated  payment 
system,  DTRS  will  also  support  electronic  auditing  and  payment.  DoD  has  also 
mstalled  a  telecommunications  network  and  developed  fte  EDI  standards  re¬ 
quired  for  exchanging  electronic  shipment  and  invoice  information  with  its  com¬ 
mercial  trading  partners.  Further,  MTMC  has  modified  its  regulations,  policies, 
and  procedures  to  permit  the  use  of  electronic  versions  of  the  GBL. 

Figure  1-4  shows  the  operating  concept  of  the  DTEDI  program.  When  fully 
operational,  the  program  will  involve  more  than  600  CONUS  shipping  activities, 
three  treinsportation  payment  centers,  and  MTMC.  Chapter  3  presents  more  de¬ 
tails  on  the  operating  concept  and  requirements  for  the  DTEDI  program. 
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Figure  1-4. 

DTEDI  Operating  Concept 


While  the  initial  focus  of  the  DTEDI  program  is  to  support  the  electronic 
audit  and  payment  of  freight  and  personal  property  shipment  invoices,  the  EDI 
infrastructure  it  establishes  will  enable  the  DoD  to  capture  much-needed  CONUS 
source  data  for  ITV.  The  DoD  issues  more  than  1.3  million  freight  GBLs  every 
year.  Over  80  percent  of  those  GBLs,  and  the  associated  TCNs,  are  generated  at 
shipping  activities  targeted  by  the  DTEDI  program.  Furthermore,  MTMC's 
newly  developed  CONUS  Freight  Management  (CFM)  system  will  capture  the 
shipment  information  necessary  for  ITV  applications. 
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In  February  1994,  the  DoD  implemented  the  DTEDI  program  at  a  handful  of 
shipping  activities,  a  few  commercial  carriers,  DFAS-IN,  and  MTMC. 


TC  AIMS 


In  1987,  the  Joint  Staff  established  a  requirement  for  each  Military  Service  to 
develop  an  automated  system  for  providing  unit  movement  ITV  information 
from  CONUS  origin  to  the  POD.  In  response  to  that  requirement,  the  Army  is 
fielding  the  Transportation  Coordinator  —  Automated  Command  and  Control 
Information  System  (TC  ACCIS);  the  Air  Force  is  fielding  the  Cargo  Movement 
Operating  System  (CMOS);  and  the  Marine  Corps  has  fielded  the  Marine  Air 
Ground  Task  Force  II  Logistics  Automated  Information  System  (MAGTF II/ 
LOGAIS).  Together,  those  three  systems  comprise  the  Transportation  Coordina¬ 
tor's  Automated  Information  for  Movement  System  (TC  AIMS)  family  of  sys¬ 
tems. 


Defense  Transportation  Tracking  System 

Commercial  motor  carriers,  under  contract  to  the  DoD,  transport  more  than 
55,000  arms,  ammunition,  and  explosive  shipments  each  year  throughout 
CONUS.  Because  of  their  high  level  of  public  exposure  and  sensitivity,  DoD  re¬ 
quires  that  those  shipments,  as  well  as  an  increasing  number  of  hazardous  mate¬ 
rial  shipments,  be  monitored  from  origin  to  destination.  The  Defense 
Transportation  Tracking  System  (DTTS),  located  in  Norfolk,  Va.,  performs  that 
task  using  both  motor  surveillance  and  satellite  monitoring.^ 

DTTS  receives  shipment  information  in  a  variety  of  formats  (phone,  facsim¬ 
ile,  and  remote  terminal  entry)  from  over  200  activities.  It  then  links  shipment 
information  to  hourly  automatic  position  reports  received  via  satellite  from 
transponders  attached  to  the  commercial  trucks  transporting  the  shipments. 
Those  transponders  also  provide  emergency  position-location  messages  to  DTTS 
and  the  parent  carrier  during  accidents  and  emergencies. 

The  use  of  DTTS  is  expanding  rapidly.  In  FY91,  it  tracked  the  movement  of 
approximately  16,000  ammunition  shipments.  Three  years  later,  the  number  of 
shipments  tracked  has  increased  to  55,000.  To  keep  pace  with  this  growth,  DTTS, 
in  conjunction  with  MTMC's  CFM  system,  is  implementing  the  use  of  EDI  to  re¬ 
ceive  GBL  information  electronically  from  ordnance  shippers  that  participate  in 
the  DTEDI  program. 


^The  Naval  Sea  Systems  Command  (NAVSEA)  and  the  Naval  Supply  Systems  Com¬ 
mand  (NAVSUP)  jointly  developed  DTTS;  MTMC  is  the  program  manager;  the  Naval 
Ordnance  Command  (NOC)  serves  as  the  executive  agent  for  systems  development;  and 
the  Navy  Material  Transportation  Office  (NAVMTO)  is  the  system  operator. 
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Defense  Total  Asset  Visibility 


In  March  1994,  the  DUSD(L)  sponsored  a  Total  Asset  Visibility  Conference. 
The  purpose  of  this  corrference  was  to  identify  the  "most  successful"  government 
and  industry  practices,  review  adaptable  technologies  and  approaches,  and  de¬ 
velop  road  maps  for  implementing  TAV.  Implementation  is  to  focus  on  two 
categories  of  TAV  users:  operating  users  (units.  Military  Service  headquarters, 
and  weapon  system  managers)  and  logistics  system  users  (principally  retail  and 
wholesale  inventory  managers,  and  transportation  managers). 

Since  that  conference,  the  DUSD(L)  has  established  the  TAV  JTF  to  identify 
the  required  TAV  systems  architecture  and  develop  a  plan  for  its  implementa¬ 
tion.  The  TAV  JTF  will  recommend  numerous  enhancements  to  the  supply, 
transportation,  maintenance,  and  production  segments  of  the  logistics  pipeline 
for  purposes  of  achieving  a  "seamless"  logistics  system.  The  technical  architec¬ 
ture  for  such  a  system  would  include  fully  integrated  intransit,  inprocess,  and  in¬ 
storage  asset  visibility  modules.  (Chapter  2  of  this  report  discusses  the 
integration  of  GTN's  ITV  capability  with  the  greater  TAV  program.) 


Automatic  Identification  Technology 

Use  of  electronic  tagging  media  to  mark  the  contents  of  containerized  and 
palletized  shipments  is  vital  to  achieving  ITV,  particularly  in  theaters  where  ade¬ 
quate  communications  capacity  for  logistics  information  exchanges  cannot  be  en¬ 
sured.  Those  media,  commonly  referred  to  as  automatic  identification 
technology  (AIT),  are  to  employ  a  standard  supply  and  transportation  data  set 
for  documenting  the  contents  of  surface  containers  and  air  pallets.  The  require¬ 
ments  for  that  data  set  were  detailed  in  a  Deputy  Assistant  Secretary  of  Defense 
(Logistics)  memorandum  of  9  September  1992.  Some  of  the  features  of  AIT  are  to 

♦  identify  the  contents  of  containers,  pallets,  and  consolidated  shipments  from 
line-item  manifest  and  packing  information; 

♦  provide  container-content  detail  (resupply  line  item  detail  data)  on  a  single 
tag; 

♦  transfer  of  container  or  pallet  content  data  automatically  into  unit  and  thea¬ 
ter  supply  data  bases; 

♦  share  data  with  a  variety  of  commercial-  and  government-owned  computer 
hardware; 

♦  enable  worldwide  interoperability  and  technology  certification; 
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♦  operate  in  warehouses,  terminal  facilities,  ocean  vessels,  aircraft,  land  vehi¬ 
cles,  and  all  DoD  equipment  used  for  moving  containerized,  imitized,  and 
palletized  shipments; 

♦  operate  in  a  wide  range  of  outdoor  environments,  from  deserts  to  open  seas; 
and 

♦  operate  Scifely  in  close  proximity  to  munitions  and  hazardous  material. 


Summary 

Dining  the  past  five  years,  DoD  has  launched  several  ITV  initiatives.  In  par¬ 
ticular,  USTRANSCOM  has  made  considerable  progress  m  laying  the  founda¬ 
tion,  through  GTN,  for  a  DoD-wide  ITV  capability.  As  presently  configured, 
however,  GTN  will  not  provide  the  necessary  visibility.  Significant  gaps  still  ex¬ 
ist  in  both  the  source  (CONUS)  and  theater  portions  of  the  pipeline. 

Nonetheless,  the  DoD  needs  to  integrate  GTN  with  its  existing  ITV  and  TAV 
initiatives,  and  expand  the  capabilities  of  GTN  to  capture  CONUS  source  and 
theater  information.  When  that  integration  and  expansion  are  complete,  the  DoD 
will  have  a  powerful  ITV  capability.  This  document  presents  DoD's  plan  for  de¬ 
veloping  such  a  capability.  The  components  of  the  plan  are  presented  in  four 
chapters  and  three  appendices: 

♦  Chapter  2  describes  the  DoD's  ITV  requirements,  presents  an  overview  of 
the  system  interfaces  and  operating  concept  for  satisfying  those  require¬ 
ments,  and  identifies  the  key  issues  that  the  DoD  must  resolve  before  it  can 
successfully  implement  the  operating  concept. 

♦  Chapter  3  presents  an  operating  concept  for  ITV  based  on  the  premise  that 
GTN  is  the  central  ITV  data  base  for  Defense  cargo  and  personnel  moving 
from  origin  to  destination. 

♦  Chapter  4  sequences  the  implementation  of  the  various  operating  concept 
components  and  system  interfaces  according  to  their  feasibility  and  relative 
benefit. 

♦  Appendix  A  describes  some  of  the  key  information  systems  supporting  the 
DoD's  ITV  requirements.  Appendix  B  defines  many  of  the  terms  used  in  this 
report,  while  Appendix  C  presents  the  implementation  plans  for  each  func¬ 
tional  area  of  ITV. 
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Chapter  2 


Requirements  and  Key  Considerations 


Introduction 

This  chapter  presents  the  DoD's  requirements  for  ITV,  the  impediments  to 
achieving  ITV,  cind  the  recommended  approaches  for  resolving  those  impedi¬ 
ments.  To  ensure  participation  throughout  the  Defense  community  and  gam  a 
consensus  on  the  requirements  and  the  operating  concepts  that  support  those  re¬ 
quirements,  USTRANSCOM  formed  several  action  teams  consisting  of  represen¬ 
tatives  from  the  Military  Services,  DLA,  transportation  component  commands 
(TCCs),  Joint  Staff,  CINCs,  cind  OSD.  USTRANSCOM  tasked  each  action  team  to 
address  one  functional  area  of  ITV  —  unit  and  non-unit  cargo,  unit  and  non-unit 
passengers,  medical  patients,  and  personal  property.  USTRANSCOM  elected  to 
partition  ITV  into  those  areas  because  they  have  different  requirements,  operat¬ 
ing  concepts,  and  automated  systems;  it  also  sought  to  divide  the  implementa¬ 
tion  effort  into  manageable  programs. 

In  some  cases,  such  as  with  the  CONUS  portion  of  non-unit  cargo,  the  ac¬ 
tion  teams  met  formally.  In  others,  action  team  members  were  interviewed  indi¬ 
vidually.  In  all  cases,  the  ITV  requirements  and  the  operating  concepts  for 
achieving  them  were  fully  documented. 


Requirements 

The  DoD  has  several  requirements  for  an  ITV  system.  It  must  track  person¬ 
nel  movements  from  origin  to  destination.  It  must  identify  the  contents  of  a  ship¬ 
ment  and  monitor  the  shipment's  location  as  the  shipment  moves  from  origin  to 
destination.  The  ITV  system  must  be  linked  to  command  and  control  systems 
such  as  Joint  Operation  Planning  and  Execution  System  (JOPES)  and  ultimately 
the  GCCS.  It  must  enhance  the  DoD's  ability  to  track  individual  requisitions, 
items,  and  unit  movements;  reconstitute  shipments;  and  divert  shipments  to  new 
destinations.  It  must  also  have  the  capability  to  operate  from  origin  to  destina¬ 
tion  (including  redeployments  and  retrograde  shipments);  be  available  during 
peace,  contingencies,  and  war;  and  support  both  the  operations  and  logistics 
communities.  Each  of  these  requirements  is  described  in  more  detail  below. 


Track  Personnel  Movements 

Modem  commercial  communications  and  instantaneous  media  coverage  of 
personnel  movements  have  placed  additional  demands  upon  the  DoD  to 
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maintain  constant  visibility  of  personnel  moving  to  and  from  overseas  theaters. 
Although  some  ITV  of  personnel  movements  exists,  that  visibility  is  obtained 
through  manual  entry  of  non-standard  manifest  data.  USTRANSCOM  and  the 
Military  Services  have  already  made  substantial  investments  in  developing  auto¬ 
mated  systems  to  obtain  detailed  personnel  and  patient  evacuation  information, 
but  those  systems  are  neither  fully  fielded  nor  linked  to  share  information.  Since 
DoD  has  a  requirement  to  maintain  visibility  of  all  Defense  personnel,  including 
medical  patients,  moving  on  organic  and  commercial  transportation  in  peace  and 
war,  it  needs  a  responsive,  totally  integrated  persormel  movements  tracking  sys¬ 
tem  that  provides  access  to  commercial  reservations  systems  for  purposes  of  re¬ 
trieving  passenger  information. 


Identify  Shipment  Contents 

As  shipments  move  from  origin  to  destination,  every  activity  that  handles 
them  requires  some  level  of  content  information.  While  most  transportation  ac¬ 
tivities  do  not  need  detailed  shipment-content  data,  materiel  management  cen¬ 
ters  and  movement  control  centers  require  item-  and  TCN-level  data  to  route 
shipments  to  locations  that  most  need  the  material.  Detailed  content  data  are  also 
needed  when  shipments  reach  their  final  destinations. 

USTRANSCOM  is  developing  GTN  to  become  the  central  data  base  for  DoD 
content-level  data.  In  addition,  AITs  can  provide  auxiliary  capability  in  the  ab¬ 
sence  of  either  an  adequate  theater  logistics  communications  capacity  or  a  theater 
system. 


Determine  Shipment  Locations 

The  GTN  Version  2  prototype  relies  on  various  military  port  systems  to  pro¬ 
vide  status  updates  when  shipments  enter  and  leave  ports.  Once  a  shipment  is 
imder  a  commercial  carrier's  control,  however,  the  GTN  prototype  is  xmable  to 
report  location  changes  imtil  the  shipment  is  offloaded  at  another  DoD  port. 
Even  when  GTN  expands  its  interfaces  to  CONUS  and  theater  DoD  systems,  it 
will  not  have  location  visibility  over  shipments  as  they  move  between  DoD  ac¬ 
tivities.  This  level  of  location  visibility  is  not  sufficient  for  some  shipments. 

One  technique  for  enhancing  DoD's  shipment  location  visibility  is  through 
EDI  interfaces  with  commercial  carriers.  Today,  many  CONUS  carriers  provide 
EDI  status  messages  to  their  customers  on  a  regular  basis.  The  DoD  could  use  the 
information  in  those  messages  to  enhance  its  ability  to  track  assets  while  intran¬ 
sit. 


Track  Requisitions  and  Items 

The  operating  concept  must  support  not  only  the  ITV  requirements  of  the 
transportation  community,  but  also  those  of  supply,  maintenance,  and  theater 
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commands.  As  a  consequence,  DoD  needs  more  visibility  over  its  shipments  than 
either  the  manifest  or  TCN  provides.  It  needs  visibility  down  to  the  requisition 
number;  NSN;  unit  identifier  code  (UIC);  unit-line  number  (ULN);  or  other 
unique  identifier. 


Track  Unit  Movements 

The  current  national  military  strategy  of  force  projection  makes  the  tracking 
of  units  during  deployments  particularly  crucial.  The  process  of  tracking  units 
begins  with  the  capture  of  ITV  information  from  the  origin  site  and  continues 
with  updated  movement  information  throughout  the  deployment  process.  The 
key  nodes  for  reporting  movement  information  are  the  initial  deployment  site, 
aerial  or  surface  POEs  and  PODs,  intermediate  staging  bases,  and  destination. 


Identify,  Reconstitute,  and  Divert  Shipments 

Theater  commanders,  logistics  planners,  and  shippers  must  have  visibility 
over  cargo  and  persormel  movements.  Ships  and  aircraft  are  subject  to  mechani¬ 
cal  breakdowns  and  enemy  action,  and  the  flow  of  battle  often  results  in  changed 
materiel  requirements.  In  recognition  of  these  potential  changes,  the  DoD  needs 
to  enhance  its  reconstitution  and  diversion  capabilities.  The  breakdown  and  sub¬ 
sequent  cross-loading  of  the  Fast  Sealift  Ship  (FSS)  Antares  and  the  enroute  di¬ 
version  of  the  critical  Patriot  missile  reloads  during  the  Persian  Gulf  War  are 
recent  examples  of  this  requirement. 


Provide  Visibility  from  Origin  to  Destination 

The  origin  of  a  shipment  is  defined  as  the  point  where  a  unit  begins  deploy¬ 
ment,  an  installation  transportation  officer  assigns  a  TCN,  a  commercial  vendor 
initiates  the  movement  of  assets  to  a  Defense  activity,  or  a  passenger  (patient)  be¬ 
gins  travel.  The  destination  is  the  location  where  an  item  is  consigned,  a  unit  is 
deployed,  or  a  passenger  (patient)  is  traveling.  In  the  case  of  redeployments  or 
retrograde  shipments,  the  origin  is  the  current  location  and  the  destination  is  a 
new  CONUS,  intratheater,  or  intertheater  location. 

As  described  in  Chapter  1,  the  GTN  prototype  provides  limited  ITV  capabil¬ 
ity  between  the  POE  and  the  POD.  USTRANSCOM  plans  to  expand  that  capabil¬ 
ity  to  include  both  the  CONUS  and  theater  segments.  Within  CONUS,  DoD  has 
sufficient  capability  in  various  information  systems  to  provide  GTN  with  the  re¬ 
quired  nV  data.  The  overseas  theaters,  however,  present  a  much  greater  chal¬ 
lenge  because  many  have  neither  the  required  systems  capability  nor  the 
communications  capacity  to  transmit  intransit  data  to  GTN. 
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Provide  a  Seamless  Transition  From  Peace  to  War 


The  Military  Services,  Defense  agencies,  and  single  managers  for  air,  sea, 
and  land  transportation  have  independently  developed  and  managed  transporta¬ 
tion  systems.  MILSTAMP  and  the  Defense  Transportation  Management  Regula¬ 
tion  (DTMR)  provided  the  policies,  procedures,  and  data  standards,  but  they  did 
not  attempt  to  coordinate  or  integrate  the  DoD's  air  and  surface  systems.  Al¬ 
though  joint  doctrine  sought  to  build  an  integrated  transportation  capability 
from  independent  systems  for  crisis  operations,  it  always  fell  short.  As  a  result, 
DoD's  peacetime  system  is  not  seamless  and  could  not  easily  support  a  rapid 
transition  to  crisis  planning  and  execution. 

In  January  1993,  DoD  Directive  5158.4,  "United  States  Transportation  Com¬ 
mand,"  strengthened  USTRANSCOM's  mission  and  gave  it  the  authority  to  inte¬ 
grate  peace  and  wartime  transportation  policies,  procedures,  and  capabilities. 
Then  in  August  1993,  the  DUSD(L)  approved  the  charter  establishing  the  Joint 
Transportation  CIM  (Corporate  Information  Management)  Center,  JTCC,  and  as¬ 
signed  it  a  mission  "to  improve  the  efficiency  and  effectiveness  of  the  DTS 
through  the  application  of  functional  process  improvement  techniques  and  the 
central  control  of  transportation-related  [command,  control,  communications, 
and  computer]  C4  system  development."  The  JTCC  was  directed  to  work  closely 
with  DoD  Components,  Joint  Logistics  System  Center  (JLSC),  and  Defense  Distri¬ 
bution  Systems  Center  (DDSC)  on  all  interfaces  between  transportation-related 
C4  systems  and  DoD's  logistics  and  distribution  systems. 


Link  With  Operations  and  Logistics  Communities 

The  DoD's  ITV  system  must  be  linked  to  the  ultimate  users  of  transportation 
and  resources  —  the  theater  commanders.  It  further  needs  the  capability  to  col¬ 
lect,  integrate,  and  distribute  transportation  information  in  a  timely  manner  to 
the  decision-makers  that  control  operations  in  the  theater. 

In  the  short  term,  USTRANSCOM  will  use  GTN  to  provide  ITV  to  the  thea¬ 
ter  operations  community  through  an  interface  with  JOPES.  Eventually;  how¬ 
ever,  a  classified  GTN  subsystem  will  need  to  serve  as  the  transportation  module 
of  GCCS.  That  link  between  ITV  and  DoD's  command  and  control  systems  wiU 
enable  the  unified  commands  to  prepare  more  effective  reception  and  onward 
movement  plans  and  to  propose  transportation  asset  diversion  alternatives. 


Key  Considerations  and  Implementing  Actions 

The  USTRANSCOM's  challenge  is  far  greater  than  budding  GTN  and  devel¬ 
oping  system  interfaces  for  capturing  ITV  data  in  all  functional  areas.  Even  when 
such  a  system  is  fielded  and  all  interfaces  with  other  systems  are  established,  a 
number  of  xmresolved  policy,  procedural,  technical,  and  functional  issues  that  re¬ 
strict  ITV  would  still  remain.  Until  it  resolves  those  issues,  DoD  would  not  have 
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the  required  visibility.  Those  issues  include  poor  data  quality,  absence  of  timely 
data,  lack  of  system  and  program  integration,  insufficient  theater  communica¬ 
tions  capacity,  absence  of  a  deployable  theater  system,  incomplete  implementa¬ 
tion  of  a  system  migration  strategy,  inadequate  funding  for  system 
enhancements,  inability  to  agree  on  an  AIT  standard,  and  lack  of  an  integrated 
approach  to  TAV. 


Improve  Data  Quality  and  Timeliness 

Effective  ITV  is  possible  only  if  the  Defense  and  commercial  systems  that 
feed  GTN  provide  timely  and  complete  data  with  a  high  degree  of  accuracy.  Ex¬ 
perience  with  the  GTN  prototype  repeatedly  identified  data  sources  that  were 
unable  to  provide  data  with  those  attributes. 

As  an  example,  both  AMC  and  MTMC  estimated  in  April  1993  that  their 
POEs  received  ATCMDs  on  fewer  than  45  percent  of  all  shipments.  The  reasons 
included  lack  of  compliance  by  commercial  vendors,  processing  delays  at  the  air 
clearance  authorities,  and  batch  processing  at  MTMC  ports.  Furthermore,  the 
GTN  prototype  is  unable  in  many  cases  to  respond  accurately  to  user  inquiries, 
primarily  because  of  inadequate  compliance  with  existing  transportation  policies, 
standards,  and  procedures.  Similar  quality  and  timeliness  problems  exist  in  the 
processing  of  GBLs  and  CBLs.  Until  it  resolves  those  shortcomings,  the  DoD  will 
never  be  able  to  develop  a  reliable  ITV  system. 

Three  actions  are  key  to  the  development  of  a  comprehensive,  accurate,  and 
responsive  ITV  system: 

♦  Develop  new  transportation  regulations  and  procedures.  DoD  currently  maintains 
separate  transportation  regulations  and  procedures  for  various  transporta¬ 
tion  applications.  They  include  the  Personal  Property  Traffic  Management 
Regulation  (PPTMR),  DTMR,  and  MILSTAMP,  to  cite  three.  These  and  other 
documents  are  sometimes  out  of  date  or  redundant;  use  antiquated  stan¬ 
dards  and  formats;  and,  in  some  cases,  require  the  use  of  different  codes  for 
the  same  purpose.  In  response  to  these  shortcomings,  USTRANSCOM  is  de¬ 
veloping  a  new  Defense  Transportation  Regulation  (DTR)  that  amalgamates, 
simplifies,  and  replaces  existing  standards  and  procedures. 

♦  Improve  compliance  with  transportation  regulations  and  standards.  When  the  new 
transportation  regulations  and  procedures  are  developed,  DoD  should  stan¬ 
dardize  education,  training,  and  certification  of  Military  Service  and  Defense 
agency  transportation  agents.  Those  agents  would  be  accoimtable  for  the 
quality  and  timeliness  of  transportation  data.  Commercial  vendor  and  car¬ 
rier  compliance  with  DoD  regulations  and  procedures  could  be  ensured  by 
making  ITV  concepts  a  condition  of  all  contracts. 

♦  Develop  data  standards.  A  major  reason  for  the  poor  quality  of  DoD  transpor¬ 
tation  and  supply  data  is  the  lack  of  electronic  transmission  standards.  DoD 
needs  to  increase  the  use  of  EDI  to  fill  this  void.  Commercial  industry  has 
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learned  that  the  development  and  use  of  Accredited  Standards  Committee 
(ASC)  X12  implementation  guidelines  reduces  data  compliance  errors.  Al¬ 
though  DoD  has  begun  to  implement  large  EDI  programs,  it  needs  to  ex¬ 
pand  the  use  of  EDI.  Further,  DoD  recognizes  that  the  Electronic  Data 
Interchange  for  Administration,  Commerce,  and  Transport  (EDIFACT)  stan¬ 
dards  will  be  the  long-term  solution  for  EDI  transmissions,  particularly  in 
OCONUS.  At  this  time,  however,  implementing  EDIFACT  before  the 
American  National  Stamdards  Institute  (ANSI)  completes  its  EDIFACT  mi¬ 
gration  strategy  would  seriously  delay  several  active  Defense  EDI  programs 
and  therefore  ITV.  DoD  will  eventually  migrate  its  EDI  programs  to 
EDIFACT  when  the  migration  strategy  is  developed. 


Integrate  Systems  and  Programs 

One  of  the  primary  problems  with  the  DoD's  logistics  systems  is  the  lack  of 
system  integration.  As  a  result,  many  functions,  such  as  freight  payment,  con¬ 
tinue  to  rely  on  documents  as  their  primary  source  of  information.  Typically,  De¬ 
fense  transportation  information  is  printed  on  a  document,  mailed  to  another 
activity,  and  reentered  into  another  Defense  system.  This  manual  reentry  of  in¬ 
formation  is  costly  and  contributes  to  data  timeliness  and  accuracy  problems. 
The  same  situation  exists  in  DoD's  dealings  with  its  commercial  trading  partners. 
The  DoD  needs  to  increase  the  integration  of  its  transportation  systems  and  pro¬ 
grams  and  to  establish  better  linkages  with  its  commercial  trading  partners'  sys¬ 
tems. 


Enhance  Communications  Capacity 

To  date,  the  DoD  has  not  conducted  a  comprehensive  analysis  of  the  com¬ 
munications  requirements  of  its  transportation  systems  during  a  contingency. 
The  DoD  may  need  a  deployable  communications  infrastructure  primarily  dedi¬ 
cated  to  logistics  support.  Such  a  capability  would  be  more  immune  to  compet¬ 
ing  demands  from  higher  priority  communications  requirements.  Therefore, 
DoD  should  identify,  fund,  and  develop  additional  communications  capabilities 
if  GTN  is  to  provide  the  required  ITV  during  contingencies  and  war. 

In  addition,  DoD  needs  to  establish  an  EDI  value-added  network  (VAN)  to 
capture  shipment  and  location  status  data  from  commercial  carriers  and  vendors. 


Develop  Joint  Theater  Transportation  System 

Every  war  and  contingency  operation  since  Vietnam  has  reinforced  the  view 
that  one  of  TTV's  greatest  paybacks  is  in  the  theater  of  operations.  Although  the 
development  of  GTN  and  the  associated  communications  capability  promise  to 
result  in  the  availability  of  ITV  data  to  theater  and  other  users,  DoD  still  needs  to 
develop  and  quickly  implement  a  theater  transportation  system.  Such  a  system 
should  be  capable  of  accommodating  the  deployment,  in-theater  movement. 
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receipt,  and  redeplo5nnent  of  unit  and  non-unit  cargo  and  personnel.  It  should 
also  be  exportable  to  any  theater  worldwide  and,  at  a  minimum,  meet  the  follow¬ 
ing  requirements: 

♦  Access  DoD  electronic  communications  networks 

♦  Interface  with  automated  information  technologies 

♦  Use  ITV  data  to  support  movement  planning,  location  reporting,  and  ship¬ 
ment  receipt  processing  for  intratheater  and  intertheater  transportation 

♦  Generate  documentation  for  redeployment  and  retrograde  shipments 

♦  Interface  with  GTN  and  port  systems 

♦  Fimction  as  a  module  of  a  theater  material  management  system,  if  the  re¬ 
quirement  for  such  a  system  is  identified  by  the  JTF  on  TAV. 

Several  existing  systems,  such  as  the  TC  AIMS  suite  of  systems.  Department 
of  the  Army  Movement  Management  Systems  —  Redesigned  (DAMMS-R)  and 
Standard  Theater  Army  Command  and  Control  System  (STACCS),  provide  lim¬ 
ited  capabilities  in  theater.  However,  a  theater  transportation  system  does  not  ex¬ 
ist  and  no  organization  has  been  tasked  to  develop  such  a  system.  The  DoD  can 
develop  a  theater  transportation  system  in  a  number  of  different  ways,  including 
the  following. 

♦  Status  quo.  Under  this  alternative,  the  Military  Services  and  DLA  would  con¬ 
tinue  to  develop  theater  ITV  systems  that  meet  their  individual  needs  and 
then  independently  interface  those  systems  with  GTN  and  the  port  systems. 
Not  only  is  this  approach  expensive,  it  has  resulted  in  a  proliferation  of  sys¬ 
tems.  Furthermore,  none  of  those  systems  meets  the  needs  of  another  DoD 
Component. 

♦  Military  Service  Project  Executive  Agent.  Under  this  alternative,  one  of  the 
Military  Services  would  be  designated  a  project  executive  agent  with  respon¬ 
sibility  for  the  design,  development,  integration,  testing,  and  fielding  of  a 
theater  transportation  system.  This  alternative  would  encompass  the  risk  of 
bias  by  the  executive  agent  and  the  possibility  that  the  selected  system 
would  not  be  acceptable  to  the  other  members  of  the  Defense  ITV  commu¬ 
nity. 

♦  USTRANSCOM  Project  Executive  Agent.  Under  this  alternative, 
USTRANSCOM,  in  coordination  with  the  Joint  Staff  and  theater  CINCs, 
would  be  designated  as  an  executive  agent  with  responsibility  for  the  de¬ 
sign,  development,  integration,  and  implementation  of  a  theater  trarisporta- 
tion  system.  The  JTCC,  as  part  of  its  charter,  would  support  the  executive 
agent  by  developing  DTS  process  improvements  and  identifying  CIM  migra¬ 
tion  systems.  This  alternative  would  also  be  compatible  with  JTCC's  work 
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plan,  which  calls  for  it  to  support  GTN  source,  feeder,  and  related  systems; 
and  ITV  initiatives. 

The  last  alternative,  USTRANSCOM  management  with  JTCC  support,  ap¬ 
pears  to  be  the  most  logical  because  it  offers  the  greatest  likelihood  for  success.  It 
would  also  ensure  a  focus  on  "jointness"  by  virtue  of  USTRANSCOM's  and 
JTCCs  links  with  both  the  DUSD(L)  and  Joint  Staff. 

In  support  of  either  executive  agent  alternative,  the  JTCC  would  need  to  take 
a  number  of  actions,  including  the  following: 

♦  Develop  DTS  process  improvements  and  establish  performance  objectives 

♦  Evaluate  existing  system  functionality  to  serve  as  the  foundation  for  the 
theater  transportation  system 

♦  Compare  existing  capabilities  with  the  performance  objectives  to  identify  the 
shortfalls 

♦  Request,  through  CINC  USTRANSCOM  (CINCTRANS),  that  the  DUSD(L) 
designate  either  USTRANSCOM  or  a  Military  Service  as  the  acquisition 
agent  to  develop  the  additional  system  functionality  and  integrate  the  sys¬ 
tem 

♦  Identify  funding  requirements  and  sources 

♦  Manage  the  integration  of  the  fxmctional  areas  requiring  ITV  development 
into  the  theater  system. 

If  USTRANSCOM  is  designated  the  project  executive  agent,  and  if  the  TAV 
JTF  identifies  additional  requirements  for  a  theater  material  management  system, 
USTRANSCOM  and  JTCC  would  be  responsible  for  only  the  transportation  mod¬ 
ule  of  that  system.  They  would  be  accoxmtable  to  the  project  executive  agent  des¬ 
ignated  for  the  entire  theater  material  management  system.  A  detailed  theater 
transportation  system  implementation  plan  is  provided  in  Appendix  C. 


Implement  System  Migration  Strategy 

The  JTCC,  as  part  of  its  charter,  has  developed  a  migration  strategy  for 
DoD's  transportation  systems.  When  implemented,  that  strategy  will  simplify  the 
technical  architecture  required  to  support  ITV  by  reducing  the  number  of  system 
interfaces  and  making  more  efficient  use  of  system  development  and  mainte¬ 
nance  funds. 

Thus  far,  JTCC  has  selected  migration  systems  for  only  three  systems  that 
are  part  of  the  ITV  operating  concept  —  CTN,  DTTS,  and  WPS.  References  to 
other  candidate  migration  systems  are  not  intended  to  endorse  one  system  over 
another.  In  fact,  the  systems  that  will  eventually  be  used  to  support  the 
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operating  concepts  in  this  integration  plan  will  come  from  the  JTCC  system  mi¬ 
gration  process. 


Ensure  Systems  Continuity 

While  the  DoD  develops  strategies  for  migrating  existing  systems  to  single 
CIM  systems,  the  funding  for  maintenance  and  enhancements  to  existing  systems 
has  been  drastically  reduced.  Furthermore,  some  of  the  migration  systems  lack 
the  existing  capabilities  of  their  predecessors.  These  situations  continue  to  slow 
the  implementation  of  EDI  programs,  AFT  integration  efforts,  policy  and  proce¬ 
dural  enhancements,  and  ITV  system  interfaces.  In  order  to  expedite  the  fielding 
of  these  programs,  the  DUSD(L)  should  require  the  Military  Services  and  DLA  to 
provide  the  necessary  resources  to  implement  key  system  enhancements  in  leg¬ 
acy  systems. 


Develop  an  Automatic  Identification  Technology  Approach 

Even  after  GTN  is  developed  and  the  required  system  interfaces  are  in  place, 
the  risk  of  inadequate  communications  capacities  in  many  potential  theaters 
throughout  the  world  will  still  be  unacceptably  high.  To  minimize  that  risk,  DoD 
needs  to  augment  its  current  data  collection  efforts  with  electronic  tagging  tech¬ 
nology. 

Chapter  1  provided  an  overview  of  the  general  requirements  for  container 
tagging  in  terms  of  a  standard  supply  and  transportation  data  set  for  document¬ 
ing  the  contents  of  containers  and  air  pallets.  A  September  1992  OSD  memoran¬ 
dum  specified  that  the  DoD's  electronic  tagging  technology  must  be  integrated 
with  current  systems,  such  as  standard  bar-code  formats  and  automated  data 
bases. 

The  Logistics  Management  Institute  reviewed  the  results  of  various  tagging 
tests,  collected  performance  measurement  data,  identified  the  strengths  and 
weaknesses  of  the  technologies  employed,  and  assessed  the  costs  for  implement¬ 
ing  the  better  technologies  throughout  the  DoD.  Those  tagging  tests  included  the 
Future-Eur-AIT  test,  which  demonstrated  the  use  of  omni-directional  radio  fre¬ 
quency  (RF)  tags;  DLA's  Automated  Manifest  System  test,  which  employed  laser 
tags  and  memory  cards;  the  Somalia  air  line  of  communication  (ALOC)  test, 
which  examined  a  combination  of  laser  and  omni-directional  RF  technology;  and 
various  laboratory  tests  of  two-dimensional  bar-code  symbology. 

This  review  concluded  that  transportation  and  supply  content  information 
should  be  captured  on  two-dimensional  bar  codes  or  laser  cards  (depending  on 
the  number  of  requisitions  in  the  shipment),  and  OSD  should  re-assess  the  Mili¬ 
tary  Services'  requirements  for  a  RF  tag  located  on  the  outside  of  shipping  con¬ 
tainers  (either  seavans  or  mil  vans).  However,  DoD  should  not  select  the  specific 
RF  technology,  omni-directional  or  reflective,  imtil  the  Defense  community 
reaches  agreement  on  the  overall  concept  of  operations  and  the  amount  of  data 
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detail  required  on  the  outside  of  the  container  for  movement,  staging,  and  diver¬ 
sion  decisions. 

Such  an  overall  concept  of  operations  should  include  the  following  princi¬ 
ples: 

♦  DoD  recognizes  that  the  carrier  industry  has  made  significant  investment  in 
ANSI/ International  Standcirds  Organization  (ISO)  tags  and  EDI. 

♦  DoD  does  not  expect  carriers  to  read  DoD's  AIT  devices. 

♦  DoD  expects  to  pay  for  any  additional  services  it  requires  beyond  common 
industry  practice. 

♦  DoD  encourages  and  will  participate  in  industry  actions  to  broaden  or  estab¬ 
lish  ANSI/ ISO  standards. 

♦  The  carrier  industry  recognizes  and  supports  DoD's  unique  need  for  data 
rich  AIT  devices  with  location  finding,  content  inquiry,  and  on-demand  ac¬ 
cess  capabilities  while  in  theater. 

USTRANSCOM  will  propose  a  strategy  that  identifies  the  technology,  oper¬ 
ating  concept,  and  implementation  plan  for  using  AIT  in  Defense  transportation. 
This  strategy  will  be  submitted  to  the  TAV  JIT  for  incorporation  into  the  overall 
TAV  strategy. 


Secure  Funding  and  Resources 

While  many  ITV  programs  have  already  been  partially  or  completely  funded 
(such  as  GTN  development  and  the  DTEDI  program),  significant  funding  and 
personnel  resources  are  needed  to  field  the  comprehensive  program  outlined  in 
this  integration  plan.  In  accordance  with  OSD  guidance,  the  Military  Service  or 
Defense  agency  identified  as  the  lead  agent  for  each  portion  of  the  ITV  operating 
concept  is  responsible  for  identifying  and  budgeting  for  the  needed  resources. 
Those  resources  include  systems  development  and  enhancement,  program  devel¬ 
opment  and  coordination,  organizational  restructuring,  and  operating  costs.  For 
system  development  and  enhancements,  OSD  will  supply  additional  funding 
guidance  as  the  JTCC  promulgates  the  transportation  system  migration  strategy. 
Potential  sources  of  funds  for  all  other  implementation  activities  include  Defense 
Business  Operations  Fxmd  —  Transportation  (DBOF-T),  direct  appropriation,  or 
other  sources. 
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Integrate  ITV  with  TAV 

The  TAV  concept  categorizes  military  materiel  as  either  inprocess,  intransit, 
or  instorage.  Those  categories  are  defined  below: 

♦  Inprocess  assets  —  all  materiel  that  are  either  on  order  from  DoD  vendors  but 
not  yet  shipped,  or  undergoing  repair  at  depot-level  organic  or  commercial 
maintenance  facilities,  or  at  intermediate  maintenance  facilities. 

♦  Intransit  assets  —  aU  personnel  and  materiel  that  are  being  shipped  from  ex¬ 
ternal  procurement  or  repair  sources,  or  moving  within  the  DoD  distribution 
system. 

♦  Instorage  assets  —  all  materiel  being  stored  at  retail  consumer  sites  (operating 
activity  storerooms  or  warehouses);  retail  intermediate  storage  sites;  contrac¬ 
tor  facilities  (as  govemment-fumished  material);  disposal  activities;  or 
wholesale  depots. 

These  categories  divide  asset  visibility  into  manageable  programs,  with 
USTRANSCOM  having  the  lead  for  one  category:  intransit.  Nonetheless,  DoD 
has  not  yet  developed  an  overall  technical  arcidtecture  for  a  long-term  TAV  pro¬ 
gram  that  incorporates  inprocess,  intransit,  and  instorage  visibility  requirements 
into  an  integrated  data  base.  Without  such  a  technical  architecture,  the  TAV  user 
would  need  to  know  whether  a  particular  asset  is  inprocess,  intransit,  or  instor¬ 
age  in  order  to  track  its  location  or  status  through  ^e  correct  system.  Further, 
every  DoD  system  data  base  supporting  TAV  would  need  to  replicate  requisition 
and  NSN  data.  To  avoid  this  situation,  OSD  established  a  TAV  JTF  to  develop  an 
operating  concept  and  implementation  plan  for  a  fully  integrated  TAV  system. 

The  ITV  requirements,  operating  concepts,  and  implementation  schedules  in 
this  integration  plan  are  consistent  with  the  efforts  of  the  TAV  JTF.  While  this  in¬ 
tegration  plan  focuses  only  on  ITV,  in  areas  where  TAV  and  ITV  overlap  (such  as 
direct  vendor  delivery  shipments,  development  of  a  theater  material  manage¬ 
ment  system,  and  implementation  of  AIT),  the  proposed  ITV  operating  concepts 
are  consistent  and  complimentary  with  those  supporting  the  TAV  program. 

The  key  to  integrating  TAV  and  ITV  is  the  development  of  a  single  TAV  user 
interface  for  all  intransit,  inprocess,  and  instorage  assets.  This  interface  is  most 
likely  to  occur  between  GTN  and  DA  AS/ Logistics  Information  Processing  Sys¬ 
tem  (LIPS),  as  well  as  other  systems.  One  approach  for  such  an  interface  is  an 
open  systems  architecture  (see  Figure  2-1).  The  ITV  module  of  GTN  would  func¬ 
tion  as  the  processor  of  intransit  status  requests,  capturing  intransit  data  from 
Defense  and  commercial  transportation  systems  and  then  updating  the  TAV  data 
base.  In  turn,  the  TAV  system  would  make  all  ITV  records  available  for  user  in¬ 
quiries. 
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Figure  2-1. 

Fully  Integrated  TAV 


Summary 


This  chapter  presents  an  overview  of  the  requirements  and  other  key  consid¬ 
erations  for  implementing  ITV.  It  identifies  a  number  of  issues  that,  if  left  unre¬ 
solved,  would  prohibit  the  DoD  from  developing  a  comprehensive  ITV 
capability.  To  resolve  those  issues,  DoD  needs  to  improve  the  timeliness  and 
quality  of  its  data;  develop  a  single,  comprehensive  transportation  policy  and 
procedure  regulation;  and  expand  the  use  of  EDI  internally  and  when  exchang¬ 
ing  information  with  commercial  carriers  and  vendors.  It  should  also  implement 
the  JTCC  migration  strategy  for  reducing  the  number  of  required  system  inter¬ 
faces,  ensure  adequate  funds  are  available,  integrate  systems  and  programs, 
ensure  systems  continuity,  integrate  ITV  with  TAV,  develop  a  theater  transporta¬ 
tion  system,  ensure  the  availability  of  adequate  commimications,  and  implement 
a  standard  tagging  technology. 
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Chapters 

Operating  Concepts 


Introduction 

The  DoD's  operating  cxJiKept  for  ITV  is  summahzcfi  in  Figure  3-1.  The  basic 
premise  of  this  operating  concept  is  that  GTN  is  the  central  ITV  data  base  for  ail 
Defense  uirit  and  non-unit  cargo  and  personnel  movmg  from  origin  to  destina¬ 
tion.  As  such,  the  ITV  module  of  GTN  svill  need  to  receive  infonnatiosi  from 
19  TCC  Military  Service,  and  DLA  systems  (this  ntsnber  may  change  as  DoD 
completes  die  system  migration  strategy). 

In  prasenting  the  c^xrating  concept.  Defense  transportation  is  divided  into 
six  functional  areas:  unit  cargo,  rxm-unit  cargo,  personal  property,  unit  person¬ 
nel,  nan-unit  penscrtnel,  and  medical  patients.  Non-anit  cargo  has  two  compo- 
neids:  O02v>L^  origin  to  POD  movements  and  POD  to  theater  destination 
movements.  Eadi  area  also  addresses  retrograde  shipments  and  redeployments, 
whoe  appropriate.  For  each  functional  area,  ongoing  iratiatives  that  conthbate 
to  nv,  unique  requirements,  and  detailed  descriptions  of  the  recommended*  7> 
operating  concept  are  also  presented. 

Appendix  C  provides  implementation  plans  for  each  of  the  operating  con¬ 
cepts  presented  in  this  dupter. 


Cargo  -  Unit  Movements 

Background 


During  three  combat  deployments  (Urgent  Fwy,  Just  Cause,  and  Desert 
Shield),  the  status  and  timing  of  unit  deployments  attracted  much  high*lcvel  in¬ 
terest  Although  JOPES  was  designed  to  provide  such  infonnation,  it  was  not 
available  during  Urgent  Fury;  it  was  pcrposdy  not  used  dazing  Just  Cause;  and 
it  was  used  witii  great  difficulty  dazing  Desert  Shidd  and,  even  thexv  only  after 
the  deployment  of  unite  was  w^  underway.  In  each  of  those  deploymente,  the 
infermatien  necessary  to  keep  key  senior  mOiteiy  officials  mfonned  was  pnv 
vided  in  patchwork  fashion  from  limited  conanand  and  control  systems  and 
through  messages,  facsimiles,  and  phone  calls.  The  DoD  also  did  not  have  a  cen¬ 
tral  repository  of  movement  rnfbmvation  that  could  provide  accurate  and  current 
visibility  infrmnation  on  deploying  unit  caiga.* 


’  Thrtxi^ioat  this  report  the  terms  tmit  cargo  and  unit  eqa^ment  are  synenymous. 
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Reproduced  From 
Best  Available  Copy 


Ongoing  Initiatives 


The  Military  Services  have  developed  a  variety  of  information  requirements 
for  deploying  units  (and  their  cargo).  To  assist  in  developing  an  automated  ca¬ 
pability  to  track  unit  deployments,  the  Joint  Staff  published  "Requirement  for  the 
Transportation  Coordinators  Automated  Information  for  Movements  System," 
SM-3-87,  Janueuy  1987.  That  document  requires  every  Military  Service  to  de¬ 
velop  the  capability  for  tracking  units  from  their  home  stations  to  POEs.  In  re¬ 
sponse  to  that  requirement,  Ae  Military  Services  developed  the  following 
systems:  Army  —  TC  ACCIS;  Marine  Corps  —  TC  AIMS;  and  Air  Force  — 
CMOS.  The  Navy  did  not  develop  a  separate  system  because  it  planned  to  adopt 
one  of  the  other  Military  Service  systems. 

The  Army  is  also  developing  two  systems  that  will  assist  in  the  tracking  of 
unit  movements  in-theater:  DAMMS-R  and  ST  ACCS. 

In  addition  to  the  TC  AIMS  systems,  MTMC,  which  operates  military  sea¬ 
ports  throughout  the  world,  uses  several  automated  systems  to  process  unit 
cargo  movements  through  its  seaports.  Those  systems  include  the  Automated 
System  for  Processing  Unit  Requirements  (ASPUR);  Terminal  Management  Sys¬ 
tem  (TERMS);  and  Department  of  the  Army  Standard  Port  System  —  Enhanced 
(DASPS-E). 

MTMC  plans  to  replace  ASPUR  with  the  Integrated  Booking  System  (IBS), 
and  TERMS  and  DASPS-E  with  WPS.  The  WPS  is  currently  installed  at  locations 
in  Europe  and  the  Pacific.  The  WPS  has  the  capability  for  deploying  to  remote 
locations  and  providing  manifest  data. 

AMC  supports  its  movement  of  unit  cargo  with  the  Consolidated  Aerial  Port 
System  II  (CAPS  II).  That  system,  which  is  currently  being  fielded  at  AMC's  aer¬ 
ial  ports,  can  be  deployed  to  remote  locations.  It  will  also  interface  with  CMOS 
so  that  manifest  information  captured  at  the  source  does  not  need  to  be  manually 
reentered  into  other  systems. 

In  addition  to  these  systems,  USTRANSCOM  is  developing  GTN  as  a  com¬ 
mand  and  control  information  system  to  support  its  mission  of  worldwide  trans¬ 
portation  management. 


Requirements 


Various  DoD  Components  need  information  on  unit  cargo  movement  for 
many  reasons.  The  TCCs  need  information  to  determine  workload  and  schedule 
lift  assets.  CINCs  and  other  commanders  need  to  know  the  status  of  unit  de- 
plo5Tnents  relative  to  closure  schedules  so  they  can  make  a  variety  of  tactical  and 
support  decisions. 
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Long-Term  ITV  Technical  C 
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As  xmit  cargo  moves  through  each  leg  of  a  deployment,  its  status  and  loca¬ 
tion  must  be  known.  In  addition  to  unit  cargo  in  a  movement  status,  ITV  infor¬ 
mation  must  also  be  available  on  Marine  Corps  unit  cargo  stored  on  amphibious 
and  maritime  pre-positioned  ships,  and  on  Army  unit  cargo  aboard  afloat  pre¬ 
positioned  ships,  even  when  the  ships  are  not  in  common-user  status.  However, 
the  current  ITV  initiatives  do  not  capture  any  information  on  unit  cargo  stored 
aboard  pre-positioned  and  amphibious  ships.  This  shortcoming  needs  to  be  cor¬ 
rected. 

Action:  OSD  and  the  Joint  Staff,  in  coordination  with  the  Military  Services, 
define  the  ITV  requirements  for  Army  and  Marine  Corps  unit  cargo  stored 
aboard  afloat  pre-positioned  and  amphibious  ships. 

All  unit  cargo  moving  through  the  DTS  must  adhere  to  MILSTAMP  and 
DTMR  requirements.  One  of  the  tenets  of  the  ITV  initiative  is  that  all  shipment 
information  should  be  captured  at  the  source  and  then  updated  at  each  node 
throughout  the  move.  When  the  Military  Services  operate  their  own  POEs  sepa¬ 
rately  from  the  TCCs,  their  TCAIMS  must  produce  a  MILSTAMP  compliant 
manifest  and  movement  data  and  then  pass  that  information  to  GTN.  Since  the 
TC  AIMSs  are  the  first  link  in  the  deployment  chain,  they  must  be  able  to 

♦  prepare  a  military  standard  shipping  label  Department  of  Defense  (DD) 
Form  1387  in  accordance  with  MILSTAMP  instructions;  the  shipping  label 
should  include  a  bar-coded  TCN;  consignee's  DoD  activity  address  code 
(DoDAAC)  and  address  m  clear  text;  transportation  accoimt  code  (TAC); 
and  piece  nximber; 

♦  prepare  and  transmit  a  TCMD;  DD  Form  1384;  and  hazardous  cargo  label 
(DD  Form  1387-2)  following  MILSTAMP  instructions;  and  GBLs  and  CBLs, 
following  DTMR  instructions;  and 

♦  transmit  TCMD,  GBL,  and  CBL  information  electronically  to  appropriate 
TCC  systems  and  GTN  using  ASC  X12  858  Transaction  Sets. 

Action:  Military  Services,  in  consultation  with  USTRANSCOM,  upgrade 
their  TC  AIMSs  to  accommodate  preparation  of  TCMD,  GBL,  CBL,  bar-coded 
shipping  labels,  and  other  MILSTAMP  and  DTMR  documentation,  and  develop 
the  capability  to  transmit  that  data  using  the  ASC  X12  858  format.  The  TCCs  and 
the  GTN  PMO  upgrade  their  systems  to  accept  ASC  X12  858  data. 


Operating  Concept 

Figure  3-2  depicts  the  operating  concept  for  the  information  flow  of  unit 
cargo  movement  from  origin  to  destination.  It  shows  unit  cargo  information  for 
organic  movements  being  passed  from  TC  AIMS  directly  to  GTN  and  the  POE. 
For  commercial  unit  cargo  movements,  information  being  passed  from  TC  AIMS 
to  CFM  and  then  to  GTN.  As  the  movement  information  passes  from  the  POE  to 
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the  POD,  or  from  the  POD  to  the  theater  destination,  the  systems  at  the  POEs 
and  PODs  will  update  GTN. 


CONUS 

origin 


POE 


WPS 
CAPS  II 
TC  AIMS 


Theater 
destination 


POD 


Note: 


STAGGS 
DAMMS-R 
TC  AIMS 

All  arrows  signify  MILSTAMP  data  transactions  unless  othenwise  annotated. 


WPS 
CAPS  II 
TC  AIMS 


Figure  3-2. 

ITV  Information  Flow  for  Unit  Cargo  Movement  (Deployment) 


The  long-term  focus  for  obtaining  unit  movement  ITV  information  is  on  sim¬ 
plicity,  particularly  on  minimizing  the  number  of  interfaces  with  other  systems. 
Until  the  JTCC  recommends  and  OSD  approves  a  migratory  TC  AIMS,  however, 
the  Military  Services'  TC  AIMSs  remain  the  primary  transportation  systems  for 
capturing  unit  deplo)rment  source  data. 

To  enstue  that  unit  cargo  ITV  data  are  standardized  from  origin  to  destina¬ 
tion,  the  Military  Services  need  to  document  all  movements  following 
MILSTAMP  and  DTMR  instructions.  However,  those  instructions  need  to  be  up¬ 
dated  and  integrated  with  other  regulations  and  procedures. 

Action:  USTRANSCOM  consolidate,  simplify,  and  standardize  all  Defense 
transportation  regulations,  instructions,  and  procedures,  including  those  in 
MILSTAMP  and  the  DTMR,  into  a  single  document. 
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Ground  Movements  From  Origin  Site 


When  commercial  groxmd  transportation  is  used  to  move  unit  equipment 
from  origin  to  a  POE,  TC  AIMS  documents  the  move,  prepares  the  GBL,  and 
passes  the  information  to  CFM.  In  turn,  CFM  provides  the  necessary  movement 
information  to  GTN. 

When  organic  military  ground  transportation  is  used  to  move  unit  equip¬ 
ment  from  an  origia  to  a  POE,  the  TC  AIMS  will  pass  the  movement  information 
directly  to  GTN. 

To  facilitate  movement  planning,  TC  AIMS  passes  advance  movement  infor¬ 
mation  through  the  shipper  service  control  offices  to  the  POE  operating  systems. 
However,  some  of  those  interfaces  do  not  exist. 

Action:  USTRANSCOM  and  the  Military  Services  ensure  that  TC  AIMS  has 
the  capability  to  provide  the  necessary  information  to  CFM  and  GTN. 


Air  Deployments 


In  keeping  with  the  objective  of  standardizing  data  and  system  interfaces, 
JTCC  needs  to  analyze  aerial  port  operating  systems  during  the  migration  strat¬ 
egy  implementation.  As  a  result,  CAPS  II  and  modules  of  TC  AIMS  that  are  used 
for  aerial  port  operations,  whether  strategic  or  remote,  could  be  merged  into  one 
aerial  port  of  embarkation/  debarkation  (APOE/  APOD)  operating  system.  That 
system  would  pass  ITV  information  to  GTN. 

Action:  JTCC  recommend  through  the  Joint  Staff,  and  DUSD(L)  approve,  a 
migration  strategy  for  aerial  port  operating  systems  that  will  interface  with  GTN 
and  theater  transportation  systems,  and  be  deployable  to  remote  locations. 


Sea  Deployments 


As  with  air  deployments  of  unit  cargo,  seaports  also  need  only  one  operat¬ 
ing  system.  Since  no  single  system  currently  exists,  JTCC  needs  to  evaluate  the 
potential  for  merging  the  modules  of  TC  AIMS  that  have  seaport  operating  capa¬ 
bility  and  WPS  into  one  seaport  operating  system.  When  unit  movement  occurs 
from  the  deplo}nnent  site,  TC  AIMS  would  provide  advance  movement  informa¬ 
tion,  through  Ae  shipper  service  control  office,  to  IBS,  WPS,  and  GTN.  Upon 
unit  arrival  at  the  seaport  of  embarkation  (SPOE),  and  subsequent  movement 
from  the  SPOE,  the  seaport  operating  system  would  update  GTN. 

Action:  JTCC  recommend  through  the  Joint  Staff,  and  DUSD(L)  approve,  a 
standard  seaport  operating  system  that  will  interface  with  GTN  and  in-theater 
transportation  systems  and  be  deployable  to  remote  locations. 
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Theater  POD  Forward  Movements 


When  unit  cargo  arrives  at  a  POD,  the  port's  operating  system  needs  to  pass 
arrival  information  to  GTN.  It  edso  needs  to  interface  with  an  in-theater  trans¬ 
portation  system  to  support  the  onward  movement  of  that  cargo  to  its  ultimate 
destination.  When  the  unit  cargo  arrives  at  its  destination,  the  in-theater  system 
passes  the  appropriate  ITV  information  to  GTN.  Although  the  in-theater  system 
does  not  currently  exist,  STAGGS  has  the  capability  to  track  Army  units  from 
POD  forward  to  destination.  That  system  along  with  DAMMS-R,  TC  AIMS,  and 
CAPS  II  could  be  the  basis  for  a  theater  transportation  system. 

Action:  OSD,  in  coordination  with  the  Joint  Staff,  designate  USTRANSCOM 
as  the  executive  agent  to  manage  the  development  of  a  theater  transportation 
system. 


Unit  Redeployment  and  Intratheater  Movements 

For  unit  redeployment  operations,  the  new  theater  transportation  system 
would  initiate  the  source  movement  data  by  capturing  information  for  unit 
movements  from  both  commercial  and  organic  systems  and  then  pass  the  infor¬ 
mation  to  GTN  and  the  port  system.  When  the  unit  cargo  arrives  at  the  theater 
POE/POD,  the  port  system  would  update  the  movement  information  and  pass  it 
to  GTN.  (See  Figure  3-3.)  This  concept  essentially  follows  the  CONUS  deploy¬ 
ment  process  except  in  reverse  order. 

For  intratheater  movements,  the  information  flow  would  essentially  be  the 
same  as  for  redeplo5anents  (again,  not  all  movements  would  involve  port  sys¬ 
tems). 

Action:  USTRANSCOM  review  joint  and  Military  Service  doctrine  and  oper¬ 
ating  publications  for  changes  that  may  be  required  to  implement  the  operating 
concept. 


Cargo  -  Non-Unit  Movements  (Origin  to  POD) 

Background 


Non-unit  cargo  includes  all  sustainment  materiel  (except  for  supplies  and 
equipment  accompanying  a  unit  during  deployment,  and  bulk  POL^  in  CONUS, 
pre-positioned  overseas,  or  afloat.  Within  CONUS,  DoD  documents  the  move¬ 
ment  of  non-unit  cargo  m  several  ways.  Most  ITOs  use  automated  systems  to 
support  the  movement  of  non-unit  cargo.  Those  systems  could  provide  the  nec¬ 
essary  ITV  over  non-unit  cargo  when  shipped  from  CONUS  mstaUations  to  a 
CONUS  destination,  POE,  or  POD.  The  sources  for  that  information  include 
TCMD,  GBL,  CBL,  and  small  parcel  manifest  documents;  and  shipment 


^Petroleum,  oil,  and  lubricants. 
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information  from  vendors,  postal  shipment  data,  ordnance  tracking  information, 
and  shipment  status  information  from  carriers. 


Theater 

origin  POE  wps 


Note:  All  arrows  signify  MILSTAMP  data  transactions. 


Figure  3-3. 

ITV  Information  Flow  for  Unit  Cargo  Movement  (Redeployment) 


This  section  presents  an  ITV  concept  of  operations  for  capturing  various 
types  of  source  data  for  GTN.  It  also  describes  ongoing  and  planned  initiatives 
that  affect  ITV,  identifies  unique  non-rmit  cargo  ITV  requirements,  proposes  an 
ITV  operating  concept,  and  discusses  changes  to  current  policies  and  procedures 
where  they  inhibit  ITV. 


MILSTAMP 

Ongoing  iNmAirvES 

Although  Version  2.1  of  the  GTN  prototype  already  captures  TCMD  data  for 
all  air  shipments,  it  only  provides  visibility  over  shipments  from  the  POE  to 
POD.  Version  2.2  adds  similar  visibility  for  surface  shipments.  AMC  estimates 
that  DoD  Components  typically  generate  more  than  600,000  air  shipments  each 
year,  while  MTMC  estimates  a  similar  number  for  surface  shipments.  In  order  to 
extend  ITV  capability  from  the  source  of  the  shipment  to  the  POE,  MILSTAMP 
must  be  extensively  modified. 
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Requirements 


In  order  to  track  TCMD  shipments  from  a  CONUS  source  to  a  port,  GTN 
must  capture  various  domestic  shipment  information,  such  as  carrier  name,  pick¬ 
up  date  and  time,  required  delivery  date,  origin  point,  and  destination. 
MILSTAMP  currently  does  not  require  the  TCMD  to  include  those  data  items. 
However,  use  of  the  ASC  X12  858  Transaction  Set  in  lieu  of  the  TCMD  would  al¬ 
low  the  DoD  to  collect  that  information.  It  would  also  simplify  the  maintenance 
of  MILSTAMP  data  through  the  increased  flexibility  offered  by  variable  length 
EDI  records.  Furthermore,  the  MODELS  (Modernization  of  the  Defense  Logistics 
Systems)  program  supports  replacing  the  TCMD  with  the  ASC  X12  858  Transac¬ 
tion  Set. 

Action:  USTRANSCOM,  Defense  Logistics  Management  Standards  Office 
(DLMSO),  and  the  TCCs  map  MILSTAMP  data  to  the  ASC  X12  858  Transaction 
Set. 


The  incorporation  of  domestic  shipment  information  into  MILSTAMP  and 
the  subsequent  migration  to  the  ASC  X12  858  Transaction  Set  is  referred  to  as  en¬ 
hancing  TCMD  data.  This  concept  is  not  new  —  the  Air  Force  Materiel  Com¬ 
mand  has  already  successfully  demonstrated  the  use  of  the  ASC  X12 
858  Transaction  Set  in  lieu  of  MILSTAMP  data.  Appendix  C  presents  the  imple¬ 
mentation  plan  for  enhancing  TCMD  data.  That  plan  includes  schedules  for  de¬ 
veloping  improved  interfaces  between  GTN  and  the  TCC  systems,  and  for 
modifying  MILSTAMP  source  data  systems  to  satisfy  the  additional  data  re¬ 
quirements  and  ensure  timely  transmissions. 


Operating  Concept 

Except  for  the  enhanced  TCMD  data,  the  operating  concept  for  using  the 
GTN  prototype  to  capture  TCMD  data  meets  the  DoD's  TTV  requirements. 
(Figxire  3-4  provides  a  schematic  of  that  operating  concept.)  DAAS  would  pro¬ 
vide  regular  transmissions  of  MILSTRIP  AS  data  to  GTN.  (The  AS  transaction 
links  the  requisition  number  to  the  TCN.)  Furthermore,  GTN  would  receive  en¬ 
hanced  TCMD  data  from  AMC's  HOST  system  for  air  shipments  and  from 
MTMC's  WPS  for  surface  shipments. 

Action:  GTN  PMO  and  MTMC  enhance  the  WPS  and  HOST  interfaces  with 
GTN  to  include  the  additional  CONUS  movement  data  requirements. 

A  major  shortcoming  with  MILSTAMP  data  (as  well  as  with  other  DoD 
source  data)  is  the  absence  of  timely  and  accurate  data  transmissions.  Without 
advance  information,  the  inclusion  of  domestic  shipment  information  in 
MILSTAMP  does  little  to  enhance  ITV  between  the  origin  and  port.  In 
April  1993,  AMC  estimated  that  its  aerial  ports  received  between  42  and  45  per¬ 
cent  of  all  ATCMD  data  before  the  associated  shipment  arrived.  MTMC  ac¬ 
knowledges  a  similar  problem  with  surface  shipments.  Subsequent  efforts  of  a 
USTRANSCOM  working  group  traced  those  problems  to  lack  of  compliance  by 
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commercial  vendors,  delays  at  clearance  authorities,  and  batch  processing  at 
MTMC  ports.  Until  those  and  other  problems  are  resolved,  the  DoD  will  not  be 
able  to  develop  a  reliable  ITV  system. 


CONUS  ITO 
Systems 


Surface  shipments 
(MILSTAMP) 


Port  systems 


Mode  clearance 
authorities 

CMOS  \  WPS 

CFM  Field  Module  HOST  (CAPS  II) 

TC  ACCIS 
TMS 
TRAMS 
DSS 

Wofe;  TMS  =  Transportation  Management  System;  DSS  =  Distribution  Standard  System. 


GTN 


Figure  3-4. 

MILSTAMP  (ATCMD)  Data  —  Operating  Concept 


GBL  Data 

Ongoing  Initiatives 

In  February  1994,  DoD,  through  its  DTEDI  program,  began  replacing  the 
GBL  and  other  routine  freight  and  personal  property  payment  documents  with 
electronic  transactions.  It  eventually  plans  to  install  EDI  capability  at  more  than 
160  of  its  largest  CONUS  shipping  activities  as  well  as  at  DFAS-IN  ^d  MTMC. 

While  the  initial  focus  of  the  DTEDI  program  is  to  support  the  electronic 
audit  and  payment  of  freight  and  personal  property  shipments,  the  associated 
EDI  infrastructure  will  enable  the  DoD  to  capture  much  needed  CONUS  source 
data  for  ITV.  The  DoD  currently  issues  approximately  1.3  million  freight  GBLs 
each  year,  with  more  than  80  percent  of  those  GBLs  generated  at  shipping  activi¬ 
ties  included  in  the  DTEDI  program.  MTMC's  CFM  system,  which  implemented 
the  capability  to  electronically  receive  and  process  GBL  information  from  select 
DLA  depots  and  all  operational  CFM  Field  Module  sites  in  February  1994,  wiU 
capture  all  GBL  information  from  DTEDI  shipping  activities.  Overall,  the  Mili¬ 
tary  Services  and  DLA  have  initiated  EDI  programs  for  at  least  10  major  trans¬ 
portation  source  data  systems  that  wiU  ultimately  be  fielded  at  more  than 
600  shipping  activities. 


Requirements 


The  nV  requirements  for  GBL  information  are  essentially  the  same  as  for 
MILSTAMP  data.  The  CFM  system  must  capture  every  TCN  in  a  shipment. 
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along  with  a  variety  of  general  shipment  information,  such  as  shipper,  commer¬ 
cial  carrier,  and  destination.  The  detailed  data  requirements  for  electronic  GBL 
information  are  described  in  Electronic  Operating  Instructions  for  Defense  Shipping 
Activities,  published  by  MTMC,  May  1994. 

In  addition  to  those  requirements,  the  Air  Force,  as  part  of  its  two-level 
maintenance  program,  requires  nearly  real-time  access  to  GBL  information  from 
GTN.  In  order  to  satisfy  this  requirement,  GTN  needs  to  receive  GBL  informa¬ 
tion  from  the  CFM  system  as  soon  as  it  receives  that  information  from  the  ship¬ 
ping  activity. 


Operating  Concept 

Figure  3-5  shows  the  operating  concept  for  providing  GBL  information  to 
GTN.  This  concept  relies  extensively  on  the  existing  EDI  relationships  between 
Defense  shipping  activities  and  the  CFM  system. 


CONUS  ITO 
Shipper/consignee 
systems 


CMOS 

CFM  Field  Module 

TC  ACCIS 

TMS 

DSOATS 

TRAMS 

DWASP 

SC&D 

NAVADS 

SDS 

DSS 

Others 


GBL/CBL/small  parcel 
data  (ASC  X12  858) 


CFM 


GTN 


Note:  DSOATS  =  Defense  Subsistence  Office  Automated  Transportation  System;  DWASP  =  Defense 
Warehousing  and  Shipping  Procedures;  SC&D  =  Stock  Control  and  Distribution;  NAVADS  =  Navy  Automated 
Transportation  and  Documentation  System. 


Figure  3-5. 

GBL/CBL/Small  Parcel  Data  —  Operating  Concept 


The  two  major  actions  that  remain  before  the  DoD  can  achieve  adequate  visi¬ 
bility  over  GBL  shipments  are  (1)  develop  an  interface  between  the  CFM  system 
and  GTN  and  (2)  expand  the  implementation  of  EDI  capability  at  Defense  ship¬ 
ping  activities.  The  CFM  system,  however,  wiU  only  be  able  to  provide  GBL  data 
to  GTN  for  shipments  originating  at  EDI-capable  shipping  activities.  Even 
though  each  system  in  Figure  3-5  is  in  the  process  of  either  planning,  developing. 
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or  fielding  an  EDI  capability,  only  a  few  Defense  shipping  activities  are  capable 
of  transmitting  GBL  information  electronically.  Furthermore,  it  will  take  years 
before  the  CFM  system  has  the  capability  to  capture  all  GBL  information  in  a 
timely  manner. 

The  lack  of  resources  available  to  modify  legacy  systems  continues  to  slow 
EDI  implementation  at  Defense  shipping  activities.  In  addition,  DLA  depots, 
which  accotmt  for  more  than  70  percent  of  all  GBL  shipments,  are  in  the  process 
of  fielding  the  Distribution  Standard  System  (DSS)  to  replace  some  legacy  sys¬ 
tems.  DSS  needs  to  have  an  EDI  capability  in  order  to  maintain  the  functionality 
of  the  DTEDI  program. 

Action:  DLA  ensure  that  DSS  is  fielded  with  an  EDI  capability  so  that  its  de¬ 
pots  retain  their  ability  to  transmit  GBL  information. 


CBL/ Small  Parcel  Data 

Ongoing  Initiatives 

Little  standardization  and  automation  currently  exists  to  support  the  elec¬ 
tronic  preparation  of  CBLs  emd  small  parcel  manifests.  Defense  shipping  activi¬ 
ties  and  commercial  carriers  use  those  documents  when  a  shipment  does  not 
meet  the  DTMR  thresholds  requiring  use  of  a  GBL.  The  CBL  is  a  non-standard 
document  prepared  by  either  the  Defense  shipping  activity  or  the  carrier.  It  pro¬ 
vides  the  carrier  with  shipment  information  and  enables  the  carrier  to  generate  a 
waybill  and  invoice.  Many  of  the  small  parcel  carriers,  such  as  FedEx  and  UPS, 
use  bar-coded  labels,  which  are  similar  to  a  CBL.  Even  though  ITOs  initiate 
more  than  800,000  CBL  shipments  and  between  2  million  and  4  million  small 
parcel  shipments  each  year,  DoD  has  no  central  data  base  for  CBL  and  small  par¬ 
cel  information.  Unlike  GBL  shipments.  Defense  shipping  activities  pay  the  cost 
of  moving  shipments  documented  with  either  the  CBL  or  small  parcel  manifest. 
Finally,  DFAS-IN  plans  to  centralize  the  payment  of  all  CBLs  at  a  single  payment 
center,  although  DoD  has  not  yet  established  policies  or  milestones  for  develop¬ 
ing  that  capability. 


Requirements 


Ideally,  the  DoD  should  have  few  differences  among  various  types  of  ship¬ 
ment  documentation,  which  means  that  the  requirements  for  the  GBL  should 
also  apply  to  the  CBL.  However,  because  of  the  lack  of  automation  and  stan¬ 
dardization  in  the  preparation  of  CBLs  and  small  parcel  manifests,  DoD  needs  to 
map  the  CBL  and  small  parcel  data  requirements  to  the  ASC  X12  858  Transaction 
Set  and  develop  a  data  convention  for  that  application. 
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Operating  Concept 


The  operating  concept  for  processing  CBL  and  small  parcel  information  is 
identical  to  that  for  GBLs  (see  Figure  3-5).  Because  this  operating  concept  would 
establish  an  infrastructure  for  capturing  CBL  information,  the  CBL  requirements 
(including  the  Air  Force's  near-real-time  processing  requirement)  and  implemen¬ 
tation  schedule  depend  upon  the  progress  of  the  DTEDI  program.  Flowever, 
before  the  DoD  can  have  adequate  visibility  over  shipments  moving  imder  CBLs, 
it  must  take  several  actions. 

Action  1:  USTRANSCOM,  in  coordination  with  the  Military  Services  and 
DLA,  develop  implementation  guidelines  for  applying  the  ASC  X12  858  Transac¬ 
tion  Set  to  CBLs,  using  the  same  data  conventions  as  those  used  for  the  CBL, 
wherever  possible. 

Action  2:  MTMC  CFM  Program  Office  develop  the  capability  to  receive  and 
process  CBL  information  from  Defense  shipping  activities. 

Action  3:  Military  Services  and  DLA  develop  the  capability  to  electronically 
transmit  CBL  data  from  their  shipping  activities  to  the  CFM  system.  (However, 
few  shipping  activities  have  the  capability  to  support  the  electronic  preparation 
of  CBLs  or  small  parcel  manifests.  Since  DSS  will  process  more  than  70  percent 
of  all  CBL  shipments,  its  enhancement  is  key  to  the  successful  implementation  of 
the  operating  concept.) 

Action  4:  DoD  change  its  policies  and  procedures  to  centralize  the  payment 
process.  CBL  payments  to  commercial  carriers  are  currently  paid  with  local  op¬ 
erations  and  maintenance  funds,  which  are  not  available  to  DFAS-IN.  DFAS-IN 
needs  to  develop  a  schedule  for  centralizing  the  payment  process. 

The  implementation  schedule  for  these  actions  is  shown  in  Appendix  C. 


Vendor  Shipments 

Ongoing  Inttiatives 

Recent  DoD  data  shows  that  more  than  one-third  of  all  Defense  shipments 
originate  from  commercial  vendors.  (In  Desert  Shield/ Storm,  36  percent  of  all 
resupply  shipments  came  directly  from  commercial  vendors.)  This  situation 
suggests  that  the  DoD  needs  to  capture  shipment  information  from  vendors  be¬ 
fore  it  can  have  an  effective  ITV  capability. 

The  capture  of  vendor-generated  shipment  information  will  become  increas¬ 
ingly  important  to  the  DoD  as  its  forces  and  inventories  shrink.  The  DoD  will  in¬ 
crease  its  use  of  transportation  to  move  limited  resources  directly  from 
commercial  plants  to  DoD  users  during  peace,  contingencies,  or  war.  Yet,  those 
vendor  shipments  pose  one  of  the  greatest  challenges  to  the  DoD's  ITV  initiative, 
primarily  because  the  DoD  has  little  control  over  its  commercial  vendors. 
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particularly  for  free-on-board  (FOB)  destination  shipments.  (FOB  origin  ship¬ 
ments  are  subject  to  the  same  MILSTAMP  and  DTMR  policies  and  regulations 
that  govern  shipments  from  Defense  shipping  activities.)  In  addition,  whether 
the  shipments  are  FOB  origin  or  destination,  not  all  vendors  comply  with  the 
DoD's  requirement  to  use  standcird  data,  such  as  requisition  numbers  and  TCNs. 
Finally,  since  the  DoD  does  not  own  the  materiel  moving  FOB  destination  until  it 
is  received  at  a  Defense  activity,  the  vendor  has  little  incentive  to  provide  timely 
and  accurate  shipment  information. 

A  few  DoD  programs  have  developed  some  limited  ITV  capability  for  ven¬ 
dor  shipments.  The  Air  Force  and  DLA  are  testing  a  system  for  shipment  track¬ 
ing  and  customs  clearance  in  Germany.  The  operating  concept  requires 
premium  transportation  air  carriers,  such  as  FedEx,  UPS,  and  Emery  Worldwide, 
to  transmit  ASC  X12  858  Transaction  Sets  to  CMOS,  whether  the  shipment  origi¬ 
nates  at  a  Defense  shipping  activity  or  a  commercial  vendor.  This  approach  wiU 
enable  the  Air  Force  and  DLA  to  begin  the  customs  clearance  process  before 
shipments  arrive  at  the  APOD. 


Requirements 


The  GTN  needs  the  same  visibility  over  all  vendor-originated  shipments 
(both  FOB  origin  and  destination)  that  it  plans  for  those  originating  at  Defense 
shipping  activities.  That  visibility  includes  tracking  a  shipment  by  either  requisi¬ 
tion  number,  NSN,  TCN,  or  shipment  identification  number. 

Action:  DoD  direct  that  the  ASC  X12  858  Transaction  Set  is  the  principle  means 
for  communicating  vendor  shipment  information. 


Operating  Concept 

As  Figure  3-6  shows,  the  DoD  has  at  least  three  alternative  operating  con¬ 
cepts  for  capturing  vendor-generated  shipment  information. 

In  the  first  alternative,  the  vendor  transmits  shipment  information  in 
ASC  X12  858  format  to  the  appropriate  TCC  system:  HOST  for  air  shipments 
moving  to  an  OCONUS  destination,  WPS  for  surface  shipments  moving  to  an 
OCONUS  destination,  and  the  CFM  system  for  all  other  shipments.  The  TCC 
system  then  passes  that  data  to  GTN.  This  alternative  would  require  DoD  to  es¬ 
tablish  an  EDI  link  with  every  commercial  vendor.  While  many  commercial  ven¬ 
dors  use  EDI  in  other  business  applications,  they  have  little  incentive  to  provide 
the  DoD  with  information  on  FOB  destination  shipments.  In  addition,  himdreds 
of  other  commercial  vendors,  typically  small,  use  little  automation  (including 
EDI)  in  support  of  their  daily  business  activities.  Finally,  the  vendor  will  likely 
charge  the  DoD  more  for  this  added  service. 
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Vendor 


TRAMS 


Figure  3-6. 

Vendor  Data  —  Alternative  Operating  Concepts 


In  the  second  alternative,  the  vendor,  as  part  of  normal  business  operations, 
provides  the  commercial  carrier  with  electronic  or  hard-copy  shipment  informa¬ 
tion.  The  commercial  carrier  transmits  the  shipment  information,  using  the 
ASC  X12  858  Transaction  Set,  to  the  appropriate  TCC  system  (HOST,  WPS,  or 
CFM),  which,  in  turn,  passes  the  information  to  GTN.  This  alternative  would  re¬ 
quire  the  DoD  to  establish  an  EDI  link  with  every  commercial  carrier.  However, 
like  commercial  vendors,  many  carriers  have  neither  an  EDI  capability  nor  an  in¬ 
centive  to  provide  shipment  information  electronically  to  the  DoD. 

Under  the  third  alternative,  the  DoD  modifies  its  MILSCAP  procurement 
policies  and  procedures  to  require  all  vendors  to  ship  Defense  assets  FOB  origin. 
This  action  would  ensure  that  all  vendor  shipments  are  imder  DoD  management 
from  origin  to  destination.  However,  the  additional  burden  of  managing  docu¬ 
ment  preparation,  data  standardization,  and  procedural  compliance  may  make 
this  alternative  too  costly,  which  limits  its  application. 

Because  of  the  complexities  associated  with  each  of  the  above  alternatives, 
the  DoD  will  probably  not  have  complete  visibility  over  all  vendor  shipments  in 
the  foreseeable  future.  Nonetheless,  the  DoD  could  use  some  features  of  the 
above  alternatives  to  increase  the  number  of  vendor  shipments  tracked. 

Alternatives  1  and  2  could  be  used  with  all  vendors  and  carriers  that  have 
the  capability  to  provide  the  required  information  electronically.  (The  Air  Force 
has  already  implemented  the  second  alternative  for  German  customs  clearance.) 
In  addition,  the  DoD  could  adopt  the  third  alternative  for  selected  high-priority 
assets  by  requiring  the  DoD  contract  management  activity  to  specify  FOB  origin 
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prior  to  procurement.  This  action  would  minimize  the  additional  requirements 
on  the  contract  management  activity. 

Action:  DUSD(L)  appoint  DLA  as  the  lead  agent  for  capturing  and  integrat¬ 
ing  vendor  shipment  data  into  GTN.  DLA,  in  conjunction  with  USTRANSCOM 
and  the  Military  Services,  should  then  assess  the  three  alternatives  and  select  the 
best  approach.  Whichever  approach  is  selected,  DLA,  in  coordination  with  US¬ 
TRANSCOM,  should  revise  transportation  and  procurement  regulations,  poli¬ 
cies,  and  procedures  (such  as  the  Federal  Acquisition  Regulation  and  MILSCAP) 
to  make  commercial  industry  accotmtable  for  providing  timely  and  accurate  data 
through  the  ASC  XI 2  858  Transaction  Set  for  all  Defense  assets  as  they  move 
from  vendor  facility  to  Defense  activity. 

This  overlap  with  the  procurement  community  emphasizes  the  need  for  a 
seamless  integration  of  all  TAV  requirements  for  vendor  shipments.  For  this  rea¬ 
son,  the  TAV  JTF  will  recommend  a  course  of  action  that  considers  not  only  in¬ 
transit,  but  inprocess  requirements.  As  a  consequence,  DLA  will  need  to  work 
closely  with  the  TAV  JTF  to  ensure  that  the  approach  used  to  capture  vendor  ITV 
data  is  consistent  with  the  TAV  JTF's  recommendations.  DLA,  as  the  lead  agent, 
will  need  to  assess  the  feasibility  of  each  alternative  for  capturing  vendor  infor¬ 
mation;  identify  the  conditions  where  the  alternatives  increase  ITV  capability; 
and  identify  the  regulations,  policies,  and  procedures  that  need  modification  to 
ensure  visibility  over  vendor  shipments.  Appendix  C  provides  an  implementa¬ 
tion  schedule  for  moving  forward  with  these  ITV  actions. 


Postal  Data 

Ongoing  Initiatives 

The  U.  S.  Postal  Service  (USPS)  moves  a  large  number  of  small  parcels  for 
Defense  shipping  activities,  but  the  exact  number  is  impossible  to  estimate  be¬ 
cause  they  are  processed  manually  with  little  documentation. 

The  USPS  has  minimal  capability  to  track  DoD  shipments.  However,  it  is 
developing  a  new  system.  Military  International  Dispatch  and  Accountability 
System  (MIDAS),  to  provide  internal  control  and  accoimtability  over  bags  of 
mail  moving  from  CONUS  gateways  to  overseas  locations.  That  system  will  en¬ 
able  the  USPS  to  track  bags  of  mail  to  overseas  PODs. 

In  addition,  the  USPS  and  Military  Postal  Service  Agency  (MPSA)  are  pilot¬ 
ing  a  program  called  the  Military  Origin-Destination  Information  System 
(MODIS).  MODIS  will  use  bar-code  technology  to  scan  MIDAS  flight  tags  at  se¬ 
lected  military  postal  facilities  within  Germany  and  capture  transit  time  data  for 
periodic  management  report  generation.  Scanning  wiU  occur  at  the  initial  point- 
of-entry  processing  hub  (the  Aerial  Mail  Terminal  at  the  Frankfurt  International 
Airport)  and  at  the  destination  military  post  office. 
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The  only  other  USPS  program  that  may  have  value  to  the  DoD's  ITV  pro¬ 
gram  is  Express  Mail,  but  it  offers  only  limited  telephonic  tracking  capability 
when  shipping  activities  request  return  receipts. 


Requirements 


The  visibility  requirements  for  a  DoD  shipment  moving  through  the  postal 
system  should  be  the  same  as  for  any  other  DoD  shipment.  However,  in  light  of 
the  current  and  planned  capabilities  of  the  USPS,  the  DoD  is  not  likely  to  have 
adequate  visibility  over  mail  shipments  in  the  near  future. 

Most  mail  shipments,  however,  have  a  lower  ITV  tracking  priority  than 
other  DoD  shipments.  For  instance,  an  F-16  avionics  black  box  moving  via  pre¬ 
mium  transportation  in  support  of  the  Air  Force's  two-level  maintenance  pro¬ 
gram  requires  more  effective  ITV  than  a  lower  priority  mail  shipment.  The 
DoD's  mode  selection  process  and  delivery  standards  automatically  designate 
shipments  for  movement  by  low-cost  carriers,  such  as  the  USPS,  when  the  requi- 
sitioner  does  not  specify  a  high-priority  delivery  standard.  As  a  consequence, 
DoD  shipping  activities  do  not  send  many  shipments  that  require  high  levels  of 
visibility  through  the  mail. 

Nonetheless,  the  mail  system  may  be  the  only  available  service  provider 
within  the  theater  of  operations,  which  is  the  situation  in  some  remote  theaters. 
Even  if  mail  shipments  are  generally  of  lower  priority  than  other  shipments,  ex- 
ceptioi^s  will  always  exist. 

Finally,  the  Military  Services  require  the  capability  to  track  mail  bags  from 
CONUS  gateways  to  overseas  destinations  (particularly  Naval  vessels).  The 
Navy's  objective  is  to  ensure  the  availability  of  regular  shipboard  mail  (letters 
and  parcels)  for  morale  purposes. 


Operating  Concept 

The  operating  concept  for  capturing  postal  shipment  information  calls  for  an 
interface  between  MIDAS  and  GTN.  MIDAS  would  provide  the  number  and 
destination  of  all  DoD  mail  bags  using  the  ASC  X12  858  Transaction  Set.  GTN 
would  use  those  data  to  provide  destinations  with  a  variety  of  information,  in¬ 
cluding  the  number  of  mail  bags,  weight,  and  expected  arrival  date.  An  alterna¬ 
tive  operating  concept  would  rely  on  an  interface  between  MIDAS  and  a  selected 
TCC  system,  which,  in  turn,  would  provide  GTN  with  postal  data. 

The  high  cost  of  developing  an  interface  between  MIDAS  and  GTN  reduces 
the  short-term  feasibility  of  attaining  ITV  of  mail  shipments.  Until  the  USPS  de¬ 
velops  systems  that  can  provide  the  DoD  with  requisition  numbers,  TCNs,  or 
NSNs  of  material  moving  through  the  U.S.  mail,  the  DoD  will  not  have  visibility 
over  that  materiel. 
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Action:  DoD  modify  its  mode  selection  procedures  to  ensure  that  items  re¬ 
quiring  ITV  are  not  shipped  through  the  USPS. 


Ordnance  Data 

Ongoing  Initiatives 

The  DTTS  currently  tracks  more  than  55,000  high-security  shipments  annu¬ 
ally  throughout  CONUS  using  satellite  and  motor  surveillance  procedures. 
Since  those  shipments  are  documented  using  the  GBL,  the  CFM  system  will  cap¬ 
ture  data  for  auditing,  payment,  and  ITV  purposes  as  described  in  the  GBL  oper¬ 
ating  concept. 

The  DTTS  receives  GBL  information  from  Defense  ordnance  shippers  imme¬ 
diately  after  carrier  pickup,  through  either  EDI,  remote  terminal,  telephone,  or 
facsimile.  It  then  creates  a  shipment-in-process  record.  At  regular  intervals,  the 
carrier's  tractor  transmits  a  message  to  a  satellite,  which  updates  DTTS  files  on 
the  location  of  the  shipment  (a  small  percentage  of  shipments  are  still  tracked 
through  regular  driver  telephone  messages). 


Requirements 


DTTS  must  track  all  security  shipments  from  the  time  the  carrier  leaves  the 
plant  or  installation  until  delivery.  In  addition,  GTN  requires  DTTS  to  respond 
to  inquiries  about  the  location  of  all  security  shipments  at  any  time.  This  may  re¬ 
quire  an  on-line  inquiry  capability  into  DTTS  for  shipment  position  and  arrival 
data. 


Operating  Concept 

As  shown  in  Figure  3-7,  Defense  ordnance  shipping  activities  with  EDI  capa¬ 
bility  would  provide  the  CFM  system  with  shipment  information  on  all  security 
shipments  when  the  carrier  takes  possession  of  the  shipment.  The  CFM  system 
immediately  passes  that  information  to  DTTS  via  a  dedicated  line.  Ordnance 
shipping  activities  that  lack  an  EDI  capability  use  facsimile,  telephone,  or  remote 
terminals  to  transmit  shipment  information  to  DTTS.  Nonetheless,  some  of  the 
shipment  information  that  GTN  requires  for  ITV  is  not  captured.  For  example, 
DTTS  records  only  the  lead  TCN  and  the  most  hazardous  commodity,  while 
GTN  requires  all  TCNs  and  commodity  descriptions  in  every  shipment. 

Action:  DTTS  Program  Office  enhance  the  system's  capabilities  to  capture  aU 
TCN  and  hazardous  coirunodity  information  for  shipments  from  non-EDI- 
capable  shipping  activities,  and  explore  expansion  of  DTTS  to  all  modes  of 
transportation  and  OCONUS. 
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The  CFM  system  provides  GTN  with  shipment  information  from  EDI- 
capable  Defense  ordnance  shipping  activities,  as  in  the  operating  concept  for  cap¬ 
turing  GBL  and  CBL  information.  When  an  inquiry  is  made  about  a  security 
shipment,  GTN  may  require  the  capability  to  receive  current  shipment  location 
status  from  DTTS.  One  way  to  satisfy  this  requirement  would  be  for  GTN  to  ini¬ 
tiate  an  on-line  inquiry  into  DTTS,  which  would  then  respond  with  the  latest  po¬ 
sition  status  data.  This  approach  would  provide  access  to  detailed  DTTS 
tracking  data  without  requiring  the  transfer  of  high  volume  hourly  shipment  po¬ 
sition  reports  from  DTTS  to  GTN. 


EDI-capable  CFM 

ordnance  shipping  system 

activity 


Figure  3-7. 

Ordnance  Shipments  —  Operating  Concept 


Three  activities  are  key  to  implementing  this  operating  concept:  expanding 
EDI  capability  to  all  ordnance  shipping  activities,  developing  an  on-line  interface 
between  DTTS  and  GTN,  and  enhancing  DTTS  to  capture  all  ITV  data  require¬ 
ments.  Detailed  implementation  plans  for  these  three  activities  are  found  in 
Appendix  C.  While  more  than  80  percent  of  ordnance  shipments  originate  from 
ITOs  that  are  scheduled  to  have  EDI  capability,  several  years  will  elapse  before 
all  Defense  ordnance  shipping  activities  are  EDI  capable.  Therefore,  the  CFM 
system  will  be  unable  to  update  GTN  with  all  required  information  on  ordnance 
shipments  for  the  foreseeable  future. 
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Carrier  Status  Data 


Ongoing  iNmAiwES 

The  Air  Force  has  implemented  an  EDI  shipment  status  system  involving 
two  small  parcel  carriers  (FedEx  and  UPS);  CMOS;  and  the  Air  Force  Logistics 
Information  File  (AFLIF).  CMOS  provides  the  small  parcel  carriers  and  AFLIF 
with  shipment  information  (currently  in  a  proprietary  format).  The  carriers  peri¬ 
odically  transmit  shipment  status  messages  in  an  ASC  X12  214  Transaction  Set 
format  to  AFLIF,  which  then  reconciles  them  with  the  shipment  information  re¬ 
cords. 

In  addition,  AMC  has  initiated  modifications  to  its  category  A  cargo  pro¬ 
gram  to  move  Army  ALOC  and  Medical  Express  cargo  via  commercial  carriers 
to  and  from  the  carriers'  commercial  gateways  for  delivery  to  final  theater  desti¬ 
nations.  The  carriers  provide  MILSTAMP  compliant  data  for  these  shipments  di¬ 
rectly  to  the  AMC  commrinications  gateway  where  the  data  can  be  captured  by 
GTN. 


Requirements 


Commercial  carriers  are  responsible  for  providing  shipment  status  messages 
when  any  of  the  following  actions  occur: 

♦  An  ocean  shipment  is  transshipped.  ' 

♦  A  change  is  made  in  the  mode  of  transportation. 

♦  A  carrier  passes  control  of  a  shipment  to  another  carrier. 

♦  A  carrier  delivers  a  shipment. 

Although  carriers  are  required  to  transmit  an  EDI  message  whenever  any  of 
the  above  actions  occur,  they  are  not  required  to  support  inquiries  about  individ¬ 
ual  shipments  from  DoD  systems. 


Operating  Concept 

Figure  3-8  shows  the  ITV  operating  concept  for  capturing  carrier  status  mes¬ 
sages.  Ocean  carriers  would  transmit  status  messages  following  the  ASC  X12 
315  Transaction  Set  format  through  a  commercial  EDI  VAN  to  TERMS  (or  WPS 
when  it  becomes  operational),  which  then  forwards  the  status  messages  to  GTN. 
In  a  similar  manner,  rail,  motor,  and  air  carriers  would  transmit  the  ASC  X12 
214  Transaction  Set  through  a  commercial  VAN  to  the  CFM  system,  which  for¬ 
wards  the  status  messages  to  GTN.  GTN  would  need  to  augment  its  interfaces 
with  TERMS  (WPS)  and  the  CFM  system  to  include  shipment  status  data. 
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In  order  to  implement  this  operating  concept,  DoD  must  ensure  that  com¬ 
mercial  VAN  services  are  available.  While  the  General  Services  Administration 
has  procured  the  services  of  a  commercial  EDI  VAN,  that  contract  expires  in  Sep¬ 
tember  1995.  In  addition,  DoD  must  ensure  that  all  or  most  carriers  can  support 
the  transmission  of  EDI  status  messages;  only  large  carriers  have  that  capability 
now. 

Action:  USTRANSCOM  ensure  that  commercial  VAN  services  are  available 
to  support  EDI  status  transmissions  from  commercial  carriers,  and  promote  car¬ 
rier  participation  in  its  ITV  efforts. 
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Figure  3-8. 

Carrier  Status  Information  —  Operating  Concept 


Cargo  —  Non-Unit  Movements  (POD 
TO  Destination) 

Background 


The  in-theater  movement  of  non-unit  cargo  is  the  responsibility  of  the  thea¬ 
ter  CINC.  Embedded  in  that  responsibility  is  the  need  to  mamtain  ITV  of  the 
cargo  while  it  is 

♦  mbotmd,  from  a  POD  to  an  in-theater  destination;  or 

♦  outbotmd  (redeployment  and  retrograde),  from  an  in-theater  origin  to  a 
theater  POE. 
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This  visibility  can  best  be  attained  by  a  single  theater  transportation  system 
that  interfaces  with  the  strategic  movement  systems  under  which  non-unit  cargo 
moves  from  its  origin  to  a  theater  point-of-entry.  Although  that  existing  system 
does  not  exist  today,  several  DoD  systems  —  both  in  being  and  tmder 
development  —  can  provide  some  of  the  information  that  should  be  available 
from  such  a  system. 

Although  JCS  Publication  4-01.3,  "Joint  Tactics,  Techniques  and  Procedures 
for  Movement  Control,"  January  1994,  addresses  theater  movement  control  re¬ 
quirements,  it  does  not  discuss  the  ITV  implications  of  movement  control.  In 
addition,  no  single  Defense  agency  or  Military  Service  is  attempting  to  develop  a 
joint  theater  transportation  system  that  can  provide  ITV  for  cargo  moving  into, 
within,  or  out  of  a  theater.  Such  a  system  could  also  provide  destination  ship¬ 
ment  receipt  information  to  GTN  and  thereby  support  the  overall  TAV  initiative. 


Ongoing  Initiatives 

The  Military  Services  have  placed  varying  degrees  of  emphasis  on  develop¬ 
ing  an  automated  in-theater  cargo  tracking  capability.  Foremost  among  those  ef¬ 
forts  is  DAMMS-R,  an  information  system  designed  to  support  movement 
management,  transportation  operations,  and  common-user  asset  control  within  a 
theater. 

In  addition,  a  number  of  other  systems  have  differing  capabilities  to  pro¬ 
vide  ITV  of  non-rmit  cargo  movements  in  and  out  of  theaters.  Those  systems  are 

♦  WPS,  a  MTMC  seaport  operating  system  for  use  at  SPOEs  and  SPODs;  it 
provides  cargo  manifest,  arrival,  and  departure  information; 

♦  CAPS  II,  an  AMC  system  for  use  at  AMC-controHed  APOEs  and  APODs;  it 
also  provides  cargo  manifest,  arrival,  and  departure  information; 

♦  TMS,  an  EDI-capable  Marine  Corps  system  currently  fielded  both  in  the 
CONUS  and  overseas;  it  plans  and  documents  fireight  shipments  moving 
through  the  DTS; 

♦  CMOS,  an  EDI-capable  Air  Force  system  fielded  both  in  CONUS  and  over¬ 
seas;  it  plans  and  documents  freight  shipments  (including  theater  freight 
warrants)  moving  through  the  DTS.  It  also  has  a  module  supporting  theater 
airlift  clearance  requirements. 

Requirements 


The  DoD's  ability  to  achieve  ITV  of  non-unit  cargo  from  the  time  it  enters  a 
theater  rmtil  it  is  delivered  to  the  consignee  depends  upon  several  factors.  The 
most  critical  ITV  requirements  for  non-unit  cargo  are  described  below. 
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As  indicated  previously,  the  primary  problem  with  DoD  achieving  visibility 
of  the  in-theater  movement  of  non-unit  cargo  is  that  "no  one  is  in  charge."  In  the 
absence  of  such  leadership,  each  of  the  Military  Services  is  pursuing  its  own 
needs  and  establishing  its  own  goals.  This  situation  needs  to  be  corrected. 

Action:  DUSD(L),  in  coordination  with  Joint  Staff,  designate  USTRANSCOM 
as  the  executive  agent  to  design,  develop,  integrate,  test,  and  implement  a  joint 
theater  transportation  system. 

The  DoD's  recent  experiences  in  the  Persian  Gulf  and  Somalia  xmderscore 
the  likelihood  of  future  military  endeavors  in  less  than  mature  theaters.  Accord¬ 
ingly,  system  selection  or  design  efforts  for  a  theater  transportation  system  must 
satisfy  movement  requirements  rmder  a  variety  of  scenarios,  rather  than  focus 
exclusively  on  a  mature  theater  environment. 

Action:  Executive  agent  ensure  that  the  theater  transportation  system  is  ex¬ 
portable  worldwide. 

The  complexity  and  diversity  of  both  Defense  transportation  and  the  com¬ 
mercial  transportation  industry,  which  moves  much  of  the  DoD's  non-unit 
cargo,  dictate  the  need  for  a  seamless  interface  between  strategic  and  theater 
transportation  movement  systems. 

Action:  Executive  agent  ensure  that  the  theater  transportation  system  is  inte¬ 
grated  with  the  intertheater  transportation  systems  supporting  the  ports  and 
GTN. 

A  seamless  interface  with  strategic  systems  is  possible  only  if  the  data  ele¬ 
ments  used  by  the  theater  system  are  common  to,  and  interchangeable  with, 
those  in  the  strategic  systems. 

Action:  Executive  agent  ensure  that  the  theater  transportation  system  uses 
the  same  data  elements  that  are  embedded  in  existing  Automated  Information 
Systems. 

The  majority  of  non-unit  cargo  will  continue  to  be  containerized  and  pallet¬ 
ized.  As  a  result,  large  numbers  of  containers  and  463L  pallets  will  enter  and  be 
dispersed  throughout  the  theater  area  of  responsibility.  A  theater  movement 
system  provides  an  ideal  vehicle  for  tracking  the  cargo  moving  on  containers  and 
pallets. 

Action:  Executive  agent  ensure  that  the  container  and  pallet  tracking  are  in¬ 
tegral  elements  of  the  theater  transportation  system. 
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Operating  Concept 


The  ITV  operating  concept  for  moving  non-unit  cargo  from  a  POD  forward 
to  its  ultimate  destination  is  similar  to  the  concept  for  moving  unit  cargo  forward 
from  a  POD. 


Deployment  Concept 

Figure  3-9  shows  the  operating  concept  for  moving  non-unit  cargo  from  a 
theater  POD  to  a  final  destination. 


A 


WPS  MILSTAMPdata 

CAPS  II 


TC  AIMS 
DAMMS-R 
CAPS  II 


Future  theater  system 


Figure  3-9. 

Non-Unit  Cargo  Movement  from  POD  to  Destination  —  Operating 
Concept 


The  POD  system  would  provide  transportation  data  to  the  theater  transpor¬ 
tation  system.  In  keeping  with  the  system  migration  process,  all  CONUS  and 
overseas  surface  and  aerial  ports  would  use  a  standard  system.  The  POD  system 
would  also  transmit  non-unit  cargo  movement  data  to  GTN. 

Upon  arrival  of  the  non-unit  cargo  in  the  theater,  the  theater  transportation 
system  would  provide  visibility  of  cargo  as  it  moves  from  the  POD  to  a  theater 
consignee.  The  theater  transportation  system  must  not  only  interface  with  the 
POD  system,  it  must  also  provide  the  in-theater  movement  and  receipt  informa¬ 
tion  to  GTN. 
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Retrograde  and  Intratheaier  Movements  Concept 


The  concept  for  moving  retrograde  cargo  from  within  a  theater  to  a  theater 
POE  is  shown  in  Figure  3-3  on  page  3-9.  (The  operating  concept  is  identical  for 
unit  and  non-unit  cargo.)  A  theater  CINC's  responsibility  for  cargo  entering  the 
theater  does  not  end  when  the  cargo  arrives  at  its  destination.  Many  items,  in¬ 
cluding  both  unit  and  non-unit  supplies  and  equipment,  are  returned  from  thea¬ 
ters  to  CONUS.  Theater  CINCs  are  also  responsible  for  the  movement  of  those 
items  from  in-theater  points-of-origin  through  their  arrival  at  a  theater  POE.  For 
simplicity  and  consistency  of  discussion,  this  plan  considers  all  returning  mate¬ 
riel  as  retrograde  cargo. 

The  visibility  of  all  retrograde  shipments  of  non-unit  cargo  must  be  pro¬ 
vided  by  a  theater  transportation  system  that  captures  pertinent  shipment  and 
item  identifying  data,  including  the  TCN  or  shipment  identification  number  of 
unit  and  non-unit  cargo,  and  then  feeds  that  data  to  the  operating  port  system 
and  GTN.  The  identifying  data  must  be  captured  from  both  commercial  and 
DoD  sources,  in  addition,  the  system  must  have  the  same  capabilities  for  retro¬ 
grade  cargo  being  moved  by  foreign  commercial  means  as  the  CFM  system  and 
TC  AIMS  have  for  producing  origin  transportation  documentation.  Upon  arrival 
of  the  retrograde  cargo  at  the  POE,  the  port  system  would  update  the  movement 
information  and  pass  it  to  GTN.  Despite  the  logical  simplicity  of  that  concept, 
the  essential  theater  transportation  system  has  not  yet  been  developed. 

For  intratheater  movements,  the  information  flow  would  essentially  be  the 
same  as  for  retrograde  movements  except  that  not  all  cargo  movements  will  in¬ 
volve  port  systems. 

Action:  Executive  agent  ensure  that  the  theater  transportation  system  cap¬ 
tures  rrV  information  from  foreign  carriers. 


Personnel  —  Unit  Movements 

Background 

Introduction 


Prior  to  1993,  the  responsibility  for  maintaining  visibility  over  intransit  per¬ 
sonnel  resided  with  the  Military  Services,  TCCs,  and  individual  units.  The  Mili¬ 
tary  Services  routinely  developed  their  own  policies  and  procedures  governing 
the  movement  of  personnel  up  to  the  point  when  they  entered  AMC's  terminals. 
The  Military  Services  and  theater  component  commands  also  operated  ah  termi¬ 
nals  and  manifested  passengers  during  peacetime  and  contingency  operations. 

The  Headquarters,  U.S.  Ah  Force  developed  and  coordinated  procedures  for 
unit  personnel  movements,  which  were  eventually  published  as  Joint  Service 
Regulations.  However,  unit  personnel  movements  are  still  accomplished  using 
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manual  procedures  developed  by  the  Military  Services.  This  situation  resulted 
from  the  Military  Services  having  responsibility  for  developing  their  own  unit 
manifesting  capability  within  the  TC  AIMS  family  of  systems. 


Desert  Shield /  Storm  Lessons  Learned 

Operations  Desert  Shield/Storm  required  an  vmprecedented  rapid  move¬ 
ment  of  personnel  from  CONUS  to  the  theater  of  operations.  Although  the  trans¬ 
portation  and  personnel  communities  met  that  challenge  through  the  innovative 
use  of  airport  infrastructure  and  communications  systems,  their  success  was  tem¬ 
pered  by  the  lack  of  ITV  of  persoimel  moving  into,  within,  and  out  of  the  area  of 
operations. 

As  a  result,  the  theater  persormel  community  could  not  track  the  identity,  lo¬ 
cation,  and  movement  schedules  of  incoming  personnel.  Furthermore,  Military 
Service  personnel  organizations  were  tmaware  of  the  number  of  passengers 
manifested  and  aircraft  arrival  times.  These  shortcomings  complicated  and  de¬ 
layed  the  plcinning  for  onward  movement  of  military  personnel.  In  addition,  ex¬ 
tensive  television  coverage  prompted  numerous  relatives  to  inquire  about 
service  members'  status,  placing  additional  demands  on  the  persormel  commu¬ 
nity. 


USTRANSCOM  Authortites 

In  January  1993,  the  Acting  Secretary  of  Defense,  under  authority  of  DoD  Di¬ 
rective  5158.4,  assigned  to  QNCTRANS  the  responsibility  to  ". . .  submit  as  nec¬ 
essary  to  the  SecDef  [Secretary  of  Defense],  through  the  CJCS  [Chairman,  Joint 
Chiefs  of  Staff],  the  USD(A&T)  [Under  Secretary  of  Defense  for  Acquisition  and 
Technology]  and  such  other  department  officials  as  may  be  appropriate,  for  ap¬ 
proval  of  any  changes  to  DoD  transportation  policies."  He  further  directed 
CINCTRANS  to  ensure  compatibility  between  peacetime  and  wartime  proce¬ 
dures.  These  actions  effectively  centralized  responsibility  for  DoD  passenger 
policy  and  procedures  at  USTRANSCOM.  CINCTRANS  subsequently  refined 
AMC's  and  MTMC's  passenger  roles  by  designating  AMC  responsible  for  deal¬ 
ing  with  industry  and  MTMC  responsible  for  dealing  with  customers.  The  Mili¬ 
tary  Services,  however,  were  to  continue  developing  independent  TC  AIMS 
capabilities  for  tracking  and  manifesting  units. 


Ongoing  Initiatives 
GTN  AND  TC  AIMS  Interface 

Recognizing  the  need  to  develop  an  interface  between  the  TC  AIMS  systems 
and  GTN,  AMC  has  published  a  draft  Interface  Design  Document  (IDD)  for  the 
AMC  Communications  Gateway,  Volume  II:  Passenger  Transactions,  dated 
21  December  1993.  The  communications  gateway  will  route  a  TC  AIMS  manifest 
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message  directly  to  GTN  or  to  both  GTN  and  PRAMS,  depending  on  the  enroute 
station  or  destination  system  requirements.  PRAMS  will  update  GTN  every 
two  hours  with  information  on  passenger  movements. 


CAPS  II  Enhancements 

In  August  1993,  AMC  began  installing  the  new  CAPS  II  system  at  its  fixed 
aerial  ports/ air  terminals.  CAPS  II  combines  passenger  processing  and  air  termi¬ 
nal  command  and  control  operations  into  one  system.  AMC  also  plans  to  install 
CAPS  II  at  all  aerial  ports  now  served  by  the  existing  Remote  Consolidated  Aer¬ 
ial  Port  System.  In  addition,  it  will  use  a  Deployable  Consolidated  Aerial  Port 
System  (DCAPS)  to  provide  real-time  passenger  ITV  information  from  deployed 
locations.  AMC  will  use  DCAPS  primarily  for  mobile  aerial  port  personnel  in 
support  of  wartime  and  contingency  mobility  operations. 


Requirements 

Standard  Manifest  Data  Elements 

USTRANSCOM  and  the  Military  Services  agree  on  the  need  for  all  manifest¬ 
ing  systems  to  use  standard  passenger  manifest  data  elements.  USTRANSCOM 
is  developing  a  standard  manifest  for  both  unit  and  non-unit  moves.  That  mani¬ 
fest  would  be  included  in  MILSTAMP  and  promulgated  to  the  Military  Services 
for  use  in  developing  their  TC  AIMS  passenger  manifesting  systems.  However, 
in  lieu  of  a  standard  format,  the  Air  Force  CMOS  community  developed  a  sepa¬ 
rate  set  of  critical  data  elements  for  manifests  and  a  standard  format.  The  use  of 
this  format  has  resulted  in  some  AMC  systems  not  being  able  to  absorb  all  of  the 
additional  critical  Air  Force  data  requirements  without  further  software  repro¬ 
gramming.  For  these  reasons,  USTRANSCOM  is  accelerating  the  development 
of  the  standard  manifest  for  unit  and  non-unit  moves. 

Action:  USTRANSCOM  develop  and  disseminate  standard  critical  manifest 
data  elements  to  the  Military  Services'  transportation  policy  managers,  TC  AIMS 
program  managers,  emd  MILSTAMP  committee. 


Sealift  Passenger  Moves 

Recent  personnel  redepIo5Tnents  by  ship  from  Somalia  surfaced  the  need 
for  an  automated  personnel  manifesting  capability.  During  Desert  Shield,  port 
operators  and  MSC  added  passengers  (supercargo)  names  onto  cargo  manifests 
or  ship  sailing  messages  to  maintain  a  record  for  immigration  purposes  and  if 
the  ship  sank.  These  procedures  were  manual. 

In  the  future,  TC  AIMS  will  create  the  passenger  manifest  and  then  pass  it  to 
WPS.  In  turn,  WPS  must  have  the  capability  to  transmit  sealift  passenger 
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manifest  data  to  GTN.  However,  currently  there  are  no  formats,  procedxnes,  or 
automated  systems  for  manifesting  passengers  on  vessels. 

Action:  USTRANSCOM  and  MTMC  ensure  that  WPS  includes  the  capability 
to  interface  personnel  manifesting  data  with  TC  AIMS  and  that  this  information 
is  transmitted,  in  an  automated  format,  to  GTN  and  the  Military  Services' 
TC  AIMS. 


Rape)  Data  Entry 


The  quick  and  accurate  entry  of  data  into  a  unit  move  passenger  manifesting 
data  base  is  essential.  CAPS  II  and  TC  AIMS  rely  on  either  manual  data  entry  or 
stored  automated  information.  Manual  data  entry  is  particularly  labor  intensive, 
time  consuming,  and  prone  to  errors.  A  Standard  Automated  Input  Media  De¬ 
vice  (SAIMD)  is  needed  to  automate  the  capturing  of  passenger  data.  The 
SAIMD  device  or  card  would  contain  information  that  can  be  rapidly  fed  into  the 
DoD's  passenger  processing  and  manifesting  systems. 

The  Joint  Staff  has  been  given  the  functional  responsibility  by  the  Assistant 
Secretary  of  Defense  (Command,  Control,  Communications,  and  Intelligence), 
ASD{C^I),  to  develop,  test,  and  field  the  Multitechnology  Automated  Reader 
Card  (MARC)  technology  in  support  of  the  medical  community.  In  addition,  the 
Army  is  testing  the  Soldier  Readiness  Card  (SRC)  to  support  mobilization.  These 
cards  contain  fixed  and  changeable  data  elements  comprised  of  bar-code,  mag¬ 
netic  stripe,  and  microchip  storage  technologies. 

Regardless  of  the  number  of  devices  or  cards  and  the  types  of  data  needed  to 
satisfy  the  functional  users,  DoD  requires  a  standard  technology  for  capturing 
data  at  the  source  that  is  compatible  with  the  data  processing  systems  supporting 
its  ITV  passenger  and  patient  processing  requirements. 

Action:  OSD  and  the  Joint  Staff  select  a  technology  and  standard  for  captur¬ 
ing  passenger  and  patient  movement  data. 

Action:  Military  Services  and  AMC  incorporate  the  selected  technology  into 
TC  AIMS  and  CAPS  II. 


Interfaces 


Although  the  personnel  mainifesting  capability  is  not  fuUy  developed  in 
TC  AIMS,  it  is  essential  to  maintain  visibility  of  deploying  personnel.  As  a  con¬ 
sequence,  the  Military  Services'  TC  AIMS  must  be  capable  of  interfacing  with 
CAPS  II,  WPS,  GTN,  joint  theater  transportation  system,  and  other  TC  AIMSs  for 
the  purpose  of  passing  unit  personnel  manifest  information.  This  requirement  is 
particularly  challenging  because  current  doctrine  permits  either  AMC  or  any 
Military  Service  to  operate  the  origin,  APOE,  APOD,  or  final  destination. 
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Action:  Military  Services  and  USTRANSCOM  ensure  that  TC  AIMS  and 
CAPS  II  have  the  capability  to  exchange  unit  move  passenger  information  and 
transmit  that  information  to  GTN. 


Operating  Concept 

The  information  source  for  unit  personnel  tracking  is  either  TC  AIMS  or 
CAPS  IT  depending  on  the  location  from  which  the  unit  deploys.  Those  systems 
must  have  the  capability  to  exchange  standard  manifest  information  and  trans¬ 
mit  that  information  electronically.  One  of  the  keys  to  this  concept  is  implemen¬ 
tation  of  a  standard  passenger  manifest.  That  manifest  must  also  be  transferable 
to  other  TC  AIMS.  Figure  3-10  depicts  the  proposed  operating  concept  for  unit 
personnel. 


POE  POD 


Note:  All  unlabeled  arrows  indicate  manifest  data  flow. 


Figure  3-10. 

Unit  Personnel  Movements  —  Operating  Concept 


For  air  movements,  TC  AIMS  or  CAPS  II  would  pass  passenger  manifest  in¬ 
formation  to  GTN.^  If  ' the  passengers  move  by  sea,  TC  AIMS  would  pass  pas¬ 
senger  information  to  WPS  and  GTN.  Upon  arrival  at  the  aerial  or  surface  POE, 
CAPS  II,  TC  AIMS,  or  WPS  would  pass  passenger  arrival  information  to  GTN. 

^The  CAPS  II  interface  with  GTN  uses  the  AMC  communications  gateway  to  access 
PRAMS.  In  turn,  PRAMS,  which  resides  on  HOST,  passes  information  received  from 
CAPS  II  to  GTN. 
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When  the  passengers  arrive  at  the  aerial  or  surface  POD  or  forward  airfield, 
CAPS  II,  TC  AIMS,  or  WPS  would  pass  arrival  information  to  GTN  and  to  the 
theater  transportation  system. 

When  a  xmit  moves  from  the  aerial  or  surface  POD  or  forward  airfield,  the 
POD  system  would  pass  passenger  movement  information  to  GTN.  At  the  desti¬ 
nation,  either  the  theater  transportation  system  or  TC  AIMS  would  advise  GTN 
that  the  unit  passengers  have  completed  their  movement. 

For  unit  redeplo5nnent  operations,  TC  AIMS  and  CAPS  II  would  operate 
like  they  would  for  a  CONUS  deployment. 


Personnel  —  Non-Unit  Movements 

Ongoing  Initiatives 

AMC  establishes  and  promulgates  non-unit  personnel  movement  proce¬ 
dures  and  develops  supporting  automated  systems.  PRAMS  is  AMC's  system 
for  plcinning  and  executing  international  non-unit  passenger  airlift  reservations. 
It  processes  airlift  reservations  for  AMC-procured  or  -controlled  aircraft  and  pre¬ 
pares  non-tmit  passenger  reservations  and  manifesting  in  peace  and  war.  It  also 
performs  flight  and  reservation  processing,  passenger  manifesting,  data  updat¬ 
ing,  data  inquiry,  reporting,  historical  data  retention,  and  system  maintenance 
procedures.  Upon  completion  of  the  reservation  fimction,  PRAMS  provides  a 
preliminary  passenger  manifest  to  the  Passenger  Automated  Check-in-System  at 
fixed  aerial  ports  and  commercial  gateways. 

AMC  is  also  building  an  interface  between  PRAMS  and  commercial  reserva¬ 
tion  systems.  The  objectives  of  this  interface  are  to  provide  base-level  PRAMS 
users  access  to  transportation  offices  worldwide  and  fulfill  future  ITV  require¬ 
ments.  The  DoD  has  approved  the  interface  system  and  made  the  necessary 
fimds  available  for  initial  implementation  at  200  DoD  sites  worldwide. 


Requirements 


The  personnel  community  and,  to  a  lesser  extent,  the  transportation  commu- 
Tuty  require  a  comprehensive  non-unit  personnel  tracking  capability. 
USTRANSCOM  plans  to  provide  that  capability  through  GTN.  The  DoD  has 
four  high-level  requirements  for  tracking  non-unit  personnel  in  GTN:  access 
commercial  reservations  systems,  capture  critical  data  elements,  interface  GTN 
with  the  Military  Service  personnel  systems,  and  book  non-crew  patient  atten¬ 
dants. 
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Access  Commercial  Reservations  Systems 


The  Defense  personnel  community  has  a  requirement  to  maintain  visibility 
of  aU  DoD  passengers  moving  on  commercial  transportation.  Although  DoD 
personnel  receive  tickets  through  various  commercial  reservations  systems  (such 
as  SABRE  and  APOLLO),  GTN  does  not  receive  any  information  on  those  move¬ 
ments.  Since  an  interface  between  PRAMS  and  commercial  reservations  systems 
is  already  being  developed  to  capture  information  on  some  passenger  move¬ 
ments,  AMC  should  expand  that  capability  to  provide  access  to  all  DoD  interna¬ 
tional  passenger  movements  (official  travel)  on  commercial  carriers.  PRAMS 
would  then  provide  that  data  to  GTN  through  an  existing  interface. 

Currently,  the  personnel  and  transportation  communities  do  not  see  a  need 
for  GTN  to  capture  domestic  passenger  movement  information.  However,  it 
would  be  beneficial  if  PRAMS  had  the  capability  to  track  these  movements  on  an 
as-needed  basis.  Preliminary  inquires  indicate  that  this  capability  is  technically 
and  economically  feasible. 

Action:  USTRANSCOM  and  AMC  establish  access  to  commercial  reserva¬ 
tions  systems  for  purposes  of  retrieving  all  DoD  international  and  overseas  offi¬ 
cial  travel,  and  the  associated  domestic  legs  of  that  travel,  for  GTN.  In  addition, 
USTRANSCOM  and  AMC  provide  the  personnel  and  transportation  communi¬ 
ties  with  the  capability  to  access  commercial  reservations  systems  to  track  DoD 
domestic  travel  on  an  as-required  basis. 


Capture  Critical  Data  Elements 

As  with  unit  manifesting,  the  Military  Services  and  USTRANSCOM  agree  on 
the  need  for  standard,  critical  non-unit  move  passenger  manifest  data  elements, 
such  as  skill  code,  gender,  and  ultimate  destination  (to  include  the  name  of  a 
Navy  ship). 

Action:  USTRANSCOM  and  AMC  ensure  that  the  interface  design  docu¬ 
ment  for  AMC's  communications  gateway  includes  skill  code,  gender,  and  ulti¬ 
mate  destination. 


Interface  GTN  With  Military  Ser\tce  Personnel  Systems 

Dming  peacetime,  ITOs  obtain  reservations  through  either  commercial 
travel  offices  or  PRAMS  terminals  installed  in  their  offices.  During  contingencies 
and  exercises,  however,  neither  the  Marine  Corps  nor  the  Army  use  those  capa¬ 
bilities.  The  Marine  Corps  assembles  planeloads  of  passengers  at  its  central  proc¬ 
essing  bases  and  requests  aircraft  via  Joint  Operations  Planning  and  Execution 
System  (JOPES)  from  USTRANSCOM  for  non-unit  passengers.  The  U.S.  Army 
Personnel  Command  (USAPERSCOM)  processes  all  Army  non-unit  personnel 
transportation  requirements  through  its  non-unit  Personnel  Flow  Computer- 
Assisted  Program  (FLOWCAP). 
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During  Desert  Shield,  USAPERSCOM  assembled  planeload  lots  of  non-unit 
personnel  and  telephonically  requested  aircraft  from  the  AMC  Passenger  Divi¬ 
sion.  AMC  then  manually  entered  manifest  data  into  CAPS  II  when  the  passen¬ 
gers  arrived  at  the  APOE.  Following  aircraft  loading,  an  Army  personnel 
detachment  at  the  APOE  updated  the  FLOWCAP  system,  which  developed  an¬ 
other  manifest  for  the  personnel  community's  use.  (In  a  related  effort,  the  Army 
Total  Distribution  Action  Plan  subsequently  directed  that  FLOWCAP  be  inter¬ 
faced  with  PRAMS  via  the  Defejise  Data  Network. ) 

The  Army  is  upgrading  its  personnel  system  with  a  new  system.  Replace¬ 
ment  Operations  Automated  Management  System  (ROAMS).  FLOWCAP  is  a 
module  of  ROAMS.  ROAMS  is  a  USAPERSCOM-turique  system  for  use  by 
CONUS  and  OCONUS  Army  commanders.  Fielded  in  February  1994,  ROAMS 
does  not  have  a  system  interface  with  PRAMS.  If  such  an  interface  existed, 
PRAMS  could  automatically  feed  passenger  information,  including  multiple 
group  blocks  and  no-name  reservation  requests,  into  GTN. 

Action:  AMC  and  Army  establish  an  electronic  interface  between  PRAMS 
and  ROAMS. 

Action:  Marine  Corps,  Navy,  and  Air  Force  determine  the  system  they  wiU 
use  to  interface  with  PRAMS  to  request  passenger  transportation  and  provide 
passenger  ITV  data  to  GTN. 


Booking  Non-Crew  Patient  Attendanis 

The  medical  community  requires  an  automated  link  between  PRAMS  and 
TRAC2ES  to  book  returning  non-crew  patient  attendants  who  are  assigned  to 
travel  with  patients  manifested  on  evacuation  aircraft  through  TRAC2ES.  When 
the  attendants  reach  the  patient's  destination  treatment  facility,  the  transporta¬ 
tion  community  ceases  classifying  them  as  patient  attendants.  It  then  categorizes 
them  as  returning  temporary  duty  non-unit  personnel.  Since  those  individuals 
are  generally  in  short  supply,  the  medical  community  needs  the  capability  to 
automatically  secure  their  return  reservations  through  PRAMS  prior  to  departure 
from  their  home  station. 

Action:  USTRANSCOM  and  AMC  develop  an  interface  between  TRAC2ES 
and  PRAMS  for  booking  returning  non-crew  patient  attendants. 


Operating  Concept 

The  Military  Services  and  supporting  CINCs  manage  the  identification  and 
movement  of  replacement  personnel  in  both  peace  and  war.  Figure  3-11  shows 
the  ITV  operating  concept  for  non-unit  personnel  movements.  It  calls  for  four 
new  system  interfaces  with  PRAMS  —  the  ITV  module  of  GTN  (this  interface  al¬ 
ready  exists  in  the  GTN  prototype);  TRAC2ES;  Military  Service  personnel  sys¬ 
tems;  and  commercial  airline  reservations  systems. 
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Figure  3-11. 

Non-Unit  Personnel  Movements  —  Operating  Concept 


Requests  for  non-unit  personnel  movement  reservations  on  channel  airlift  or 
in  planeload  lots  would  be  made  through  PRAMS.  PRAMS  would  also  provide 
seat  confirmation  and  passenger  manifest  information  to  users,  serve  as  the  pri¬ 
mary  information  collection  point  for  non-tinit  passenger  manifesting  and  move¬ 
ment,  and  transmit  the  required  information  to  GTN.  All  GTN  users,  even  if 
they  do  not  have  access  to  PRAMS,  would  have  the  capability  to  track  personnel 
movements  through  GTN. 

Military  Service  personnel  systems  such  as  ROAMS  would  be  linked  to 
PRAMS,  which  would  give  the  personnel  community  the  capability  to  request 
and  receive  confirmation  of  reservations  and  maintain  ITV  of  personnel  move¬ 
ments  without  using  PRAMS  terminals.  It  would  also  eliminate  the  need  for  the 
Military  Services  to  manually  transfer  data  from  personnel  to  transportation  sys¬ 
tems.  For  example,  a  Military  Service  personnel  system  could  automatically 
transfer  seat  requirements  and  passenger  information  to  PRAMS. 

In  addition  to  the  Military  Service  personnel  systems,  PRAMS  would  be  in¬ 
terfaced  with  commercial  reservations  systems  such  as  SABRE  and  APOLLO. 
PRAMS  would  receive  international  passenger  movement  and  other  domestic 
movement  data  from  those  systems  and  then  transfer  it  to  GTN.  Finally,  an  in¬ 
terface  between  PRAMS  and  TRAC2ES  would  accommodate  the  booking  of  non¬ 
crew  patient  attendants  and  the  tracking  of  their  return  travel. 


For  non-unit  redeployment  operations,  PRAMS  and  the  Military  Service  per¬ 
sonnel  systems  would  operate  much  like  they  do  in  support  of  CONUS  deploy¬ 
ments,  including  interfaces  with  the  aerial  port  operating  systems  and  GTN. 


Personnel  —  Medical  Patients 

Background 


DoD  Directive  5154.6,  "Armed  Services  Medical  Regulating,"  April  1993, 
designates  CINCTRANS  as  the  single  manager  for  intertheater  medical  regulat¬ 
ing.  As  a  result  of  this  designation,  the  USTRANSCOM  Surgeon's  Office  has  re¬ 
engineered  patient  movement  business  practices.  Organizational  changes  to 
support  these  reengineered  practices  are  underway,  including  unification  of  the 
Armed  Services  Medical  Regulating  Office  (ASMRO)  and  Aeromedical  Evacua¬ 
tion  Control  Center  (AECC)  into  the  new  Global  Patient  Movement  Require¬ 
ments  Center  (GPMRC).  Effective  ITV  of  patients  depends  on  medical  regulating 
and  medical  evacuation.  Medical  regulating  is  the  process  that  selects  the  Medi¬ 
cal  Treatment  Facility  (MTF)  to  provide  the  next  level  of  care  or  treatment  for  a 
patient,  while  medical  evacuation  is  the  movement  of  a  patient  from  one  MTF  to 
another.  With  the  addition  of  the  medical  regulating  function,  USTRANSCOM  is 
charged  with  providing  seamless  intertheater  movement  of  patients.  Intratheater 
regulating  remains  the  responsibility  of  unified  and  specified  commands. 

DoD  Instruction  6000.11,  "Medical  Regulating,"  May  1993,  tasks 
CINCTRANS,  in  coordination  with  the  Assistant  Secretary  of  Defense  (Health 
Affairs),  to  establish  a  global  system  to  assist  in  the  command  and  control  of  in¬ 
tertheater  medical  regulating  and  aeromedical  evacuation,  and  to  provide  ITV  of 
patients  in  both  peacetime  and  contingency  operations. 


Ongoing  Initiatives 

USTRANSCOM's  Surgeon  is  establishing  new  procedures  and  developing  a 
new  patient  ITV  command  and  control  system.  Although  both  actions  are  vital, 
the  development  of  a  command  and  control  system  for  tracking  patients  in  tran¬ 
sit  is  clearly  the  most  critical.  That  system,  TRAC2ES,  integrates  the  medical 
regulating  and  air  evacuation  processes,  and  the  patient  movement  information 
from  various  theaters  into  a  centralized  global  system.  TRAC2ES  is  also  one  of 
four  modules  of  GTN. 

USTRANSCOM  began  developing  TRAC2ES  to  aid  in  managing  its  inter¬ 
theater  and  CONUS  medical  regulating  and  aeromedical  evacuation  responsibili¬ 
ties.  Several  other  DoD  Components,  including  the  DoD  Inspector  General, 
subsequently  identified  a  need  for  TRAC2ES  to  also  support  the  intratheater  pa¬ 
tient  regulating  missions  of  the  theater  CINCs.  Today,  TRAC2ES  is  being  devel¬ 
oped  to  accommodate  that  intratheater  mission,  although  mission  execution 
remains  the  responsibility  of  the  theater  CINC. 
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Requirements 


The  DoD's  requirement  for  patient  ITV  is  to  locate  and  track,  by  name  or 
other  unique  identifier,  individuals  moving  through  its  aeromedical  evacuation 
system  for  the  purpose  of  medical  treatment.  During  movement,  many  patients 
are  accompanied  by  medical  equipment  (referred  to  as  patient  movement  items, 
or  PMl)  and  attendants.  Consequently,  medical  patient  ITV  must  be  viewed  in 
terms  of  all  three  of  those  elements  —  patients,  PMI,  and  attendants  —  each  of 
which  must  be  tracked  with  a  varying  level  of  detail.  With  attendants,  the  re¬ 
quirement  is  for  USTRANSCOM  to  arrange  for  round-trip  transportation.  The 
concept  is  covered  under  the  non-unit  personnel  movements  section  of  the  plan. 


Operating  Concept 

The  TRAC2ES  concept,  which  was  validated  in  January  1994,  is  currently  in 
prototype  development,  with  full  operational  prototype  capability  projected  for 
the  third  qucirter  of  1997.  The  system  is  expected  to  contain  information  required 
to  support  the  new  business  processes  identified  by  the  Corporate  Information 
Management  effort  and  information  from  existing  systems.  Among  these  are  air¬ 
lift  scheduling  systems  and  existing  legacy  systems  such  as  the  Defense  Medical 
Regulating  Information  System  (DMRIS)  and  Automated  Patient  Evacuation  Sys¬ 
tem  (APES). 


Patent  ITV 


Patient  tracking  information  would  be  maintained  by  the  GPMRC  and  by 
Theater  Patient  Movement  Requirements  Centers  (TPMRC),  as  shown  in 
Figure  3-12.  Although  both  centers  would  use  similar  TRAC2ES  information 
files,  their  missions  are  different  —  TPMRC  focuses  on  medical  regulation  and 
evacuation  from  the  theater  while  GPMRC  focuses  on  the  global  allocation  of 
scarce  medical  resources. 

Upon  a  patient's  entry  into  an  MTF,  the  MTF  would  generate  a  Patient 
Movement  Request  (PMR).  If  there  is  some  doubt  whether  a  patient  requires 
evacuation,  TPLAC2ES  would  generate  an  Advance  Patient  Movement  Request 
(APMR)  based  on  the  patient's  diagnosis.  When  the  patient  is  validated  for 
evacuation,  the  MTF  would  change  the  APMR  to  a  PMR.  When  an  attendant  is 
required  to  accompany  the  patient,  the  PMR  would  contain  the  attendant's  name 
along  with  additional  identification  and  tracking  information.  Ideally,  patient 
information  should  be  provided  through  the  use  of  a  MARC,  although  manual 
data  generation  is  still  the  norm. 
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Figure  3-12. 

Medical  Patients  —  Operating  Concept 


Whenever  a  patient  can  be  treated  within  the  theater,  the  TPMRC  would 
first  regulate  the  movement  of  the  patient  within  the  theater.  If  the  patient  needs 
to  be  evacuated  to  a  CONUS  MTF,  the  TPMRC  would  provide  a  regulation- 
evacuation  solution  to  the  GPMRC  for  approval.  The  GPMRC  then  would  pass 
the  transportation  instruction  and  treatment  facility  information  through  the 
TPMRC  back  to  the  MTF  that  generated  the  PMR.  As  a  result,  TRAC2ES  would 
provide  patient  TTV,  by  name,  from  the  time  a  patient  enters  an  MTF,  through 
the  evacuation  process,  rmtil  arrival  at  the  destination  MTF  for  treatment. 

The  reliability  and  responsiveness  of  TRAC2ES  is  highly  dependent  upon 
the  timeliness  and  quality  of  information  that  it  receives.  As  a  consequence,  the 
DoD  needs  to  design  an  effective  information  source  system  at  the  MTF  level.  A 
prime  candidate  for  such  a  system  is  the  MARC.  Although  the  ASD(C^I)  has 
lead  responsibility  on  the  use  of  automated  cards,  such  as  MARC,  the  Joint  Staff 
has  the  functional  responsibility.  Recently,  the  Joint  Staff  initiated  action  to  ex¬ 
pedite  the  development,  testing,  and  fielding  of  the  MARC  media  to  support 
both  medical  and  mobility  applications. 


Patient  Movement  Items 

Life-sustaining  equipment  often  accompanies  patients  when  they  are  evacu¬ 
ated.  The  DoD  does  not  have  any  automated  systems  for  tracking  the  use  of 
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life-sustaining  critical  equipment  items,  such  as  respirators  and  ventilators. 
However,  USTRANSCOM  plans  to  use  TRAC2ES  to  monitor  the  equipment 
status  of  global  pools  of  PMIs  and  assist  in  the  redistribution  of  these  items 
among  theaters. 

The  DoD's  concept  for  tracking  critical  patient  movement  items  is  similar  to 
that  used  in  support  of  patient  tracking.  The  PMR  would  contain  the  evacuee's 
accompanying  equipment  list.  As  the  patient  and  accompanying  equipment  ar¬ 
rive  at  the  destination  MTF,  TRAC2ES  would  update  the  equipment  inventories 
in  the  global  pools.  (Global  pools  contain  information  on  equipment  types  and 
inventory  levels  at  theater  and  CONUS  locations.)  Medical  personnel  would 
then  use  that  information  to  identify  the  equipment  that  needs  to  be  returned  to 
the  theaters. 


Related  Issues 


At  the  annual  Joint  Casualty  Evacuation  Working  Group  meetings,  the  Mili¬ 
tary  Services  concurred  that  the  current  TRAC2ES  concept  satisfies  their  require¬ 
ments  for  patient  ITV.  However,  two  issues  remain  unresolved. 

The  Military  Services  agree  that  patient  tracking  and  visibility  should  be 
part  of  an  overall  personnel  system  because  the  medical  community  is  not  the 
only  user  of  patient  ITV  information.  The  personnel  community  also  needs  pa¬ 
tient  information,  particularly  when  it  must  respond  to  family  or  public  requests 
for  a  military  member's  location  and  status.  Also,  a  Joint  Casualty  and  Mortuary 
Affairs  Working  Group  convened  by  the  Under  Secretary  of  Defense  (Personnel 
and  Readiness)  is  examining  the  operating  practices  of  the  various  casualty  and 
mortuary  affairs  programs.  One  of  the  Working  Group's  objectives  is  to  identify 
the  information  requirements  for  tracking  casualties  and  human  remains.  Al¬ 
though  this  group  is  making  progress,  it  requires  the  involvement  of  the  medical 
community. 

Action:  DUSD(L)  request  the  Under  Secretary  of  Defense  (Personnel  and 
Readiness)  to  undertake  the  development  of  an  interface  between  the  DoD's 
medical  and  personnel  systems. 

The  Army,  as  the  Single  Integrated  Medical  Logistics  Manager,  has  ex¬ 
pressed  concern  about  TRAC2ES'  regulation  of  critical  PMI.  Under  the  current 
concept,  TRAC2ES  would  monitor  the  status  of  predesignated  global  pools  of 
PMIs  and  assist  in  their  redistribution  among  theaters.  Although  not  yet  fully 
defined,  the  concept  does  not  address  the  Army's  desire  for  PMI  status  (quanti¬ 
ties  and  types)  at  the  MTF  level,  which  is  the  level  where  the  Army  makes  PMI- 
related  management  decisions.  The  concept  also  fails  to  satisfy  the  Army's  need 
for  additional  PMI  information,  such  as  make,  model,  serial  number,  and  stock 
number.  USTRANSCOM  views  the  Army's  information  needs  as  a  logistics  in¬ 
formation  and  inventory  management  issue  that  is  beyond  the  scope  of 
TRAC2ES. 
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Action:  Assistant  Secretary  of  Defense  (Health  Affairs)  and  the  Army  vali¬ 
date  the  requirement  for  developing  a  separate  system  to  aid  in  managing  PMIs. 


Cargo  —  Personal  Property 

Background 


The  DoD  defines  personal  property  as  the  household  goods,  imaccompanied 
baggage,  privately  owned  vehicles,  and  mobile  homes  belonging  to  military 
members  and  civilian  employees  of  the  DoD  and  U.S.  Coast  Guard.  Upon  reas¬ 
signment  to  another  location,  the  U.S.  government  pays  for  the  movement  and 
storage  of  DoD  and  Coast  Guard  members'  and  employees'  personal  property  as 
authorized  by  governing  laws,  regulations,  and  policies.  Personal  property 
movement  and  storage  entitlements  vary  by  grade  and  circumstance  as  de¬ 
scribed  in  the  Joint  Federal  Travel  Regulation. 

DoD  Directive  4500.34,  "DoD  Personal  Property  Shipment  and  Storage  Pro¬ 
gram,"  10  April  1986,  provides  overall  DoD  policy  for  the  movement  and  storage 
of  personal  property;  designates  MTMC  as  the  program  manager;  and  authorizes 
publication  of  DoD  4500.34-R,  "Personal  Property  Traffic  Management  Regula¬ 
tion  (PPTMR),"  October  1991.  The  PPTMR  prescribes  day-to-day  operating  pro¬ 
cedures  for  personal  property  shipments. 

Although  the  DoD  Personal  Property  Shipment  and  Storage  Program  func¬ 
tions  tmder  centralized  MTMC  management,  operations  are  carried  out  at 
272  Military  Service  transportation  offices.  Located  throughout  the  United  States 
and  overseas,  and  configured,  named,  and  resourced  according  to  the  owning 
Military  Service's  standards,  those  offices  are  generically  referred  to  as  personal 
property  shipping  offices  (PPSOs). 

Commercial  carriers  perform  more  than  90  percent  of  all  DoD  personal 
property  shipments  and  the  storage  incident  to  those  shipments.  Under  the 
terms  of  a  Tender  of  Service  signed  by  carriers  and  provisions  of  through  gov¬ 
ernment  bill  of  lading  (TGBL)  and  intemational  through  government  bUl  of  lad¬ 
ing  (ITGBL)  shipments,  carriers  are  responsible  for  on-time  pickup  and  delivery, 
and  for  loss-  and  damage-free  handling. 
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Current  ITV  Capability 

The  Defense  transportation  community  concurs  that  the  current  policies  and 
procedures  governing  the  movement  and  storage  of  DoD  personal  property  pro¬ 
vide  a  reasonable  level  of  ITV  because  of  several  reasons: 

♦  Shipments  [such  as  Direct  Procurement  Method,  Code  5  (household  goods) 
and  Code  J  (unaccompctnied  baggage)]  that  move  entirely  or  partially  within 
the  DTS  enjoy  a  degree  of  ITV  by  virtue  of  the  TCNs  that  are  assigned  to 
those  shipments.  The  TCN  permits  a  shipment  to  be  identified  and  tracked. 

♦  Blue  Bark  shipments  (personal  effects  of  deceased  members  or  dependents) 
are  monitored  by  the  deceased  member's  xmit,  transportation  officers,  and 
Casualty  Assistance  Officers  from  time  of  shipment  to  ultimate  delivery. 
These  t3rpes  of  shipments  are  moved  xmder  a  manual  "Report  of  Shipment" 
process  &at  affords  some  control. 

♦  Each  carrier  wanting  to  conduct  business  with  the  DoD  must  sign  a  Tender 
of  Service  for  Personal  Property,  Household  Goods,  and  Unaccompanied 
Baggage.  The  Tender  of  Service  describes  a  number  of  ITV-related  require¬ 
ments  that  each  carrier  must  satisfy,  such  as  having  to  notify  the  origin  and 
destination  PPSOs,  prior  to  the  required  delivery  date  (RDD),  when  delivery 
by  the  RDD  is  not  possible;  providing  the  shipment's  last  known  location; 
and  furnishing  an  estimate  of  the  delay  beyond  the  RDD."* 

♦  Some  ITV  is  also  available  through  a  provision  in  International  Personal 
Property  Rate  Solicitation  1-3,  Item  532,  Intransit  Visibility  Services,  which 
requires  carriers  to  provide  shipment  status  updates  upon  request  from 
MTMC.  The  provision  requires  carriers  to  provide  ITV  on  a  specified  ship¬ 
ment  or  series  of  shipments  by  monitoring  and  reporting  movement  pro¬ 
gress  through  various  transit  points. 

Requirements 

In  view  of  those  current  ITV  capabilities,  the  Defense  personal  property 
community  concedes  there  is  little  justification  to  expand  personal  property  ship¬ 
ment  nV  and  link  it  with  a  DoD-wide  system  such  as  the  GTN.  However,  it 
also  agrees  there  are  benefits  associated  with  enhancing  those  capabilities,  such 
as: 

♦  Shipments  moving  between  CONUS  and  overseas  locations  pass  through 
numerous  nodes  (local  carrier  agents,  line-haul  carriers,  forwarders,  port 
agents,  ocean  carriers,  and  others).  These  transshipments  increase  the  op¬ 
portunities  for  loss,  damage,  delays,  and  misroutings.  ITV  —  particularly 
when  shipments  commence  and  complete  their  ocean  transit  and  when  they 
miss  their  RDD  —  could  contribute  to  reducing  such  adverse  incidents.  It 
could  also  result  in  both  financial  (in  terms  of  rental  commitments,  home 

^Tender  of  Service  Section  IV,  Paragraph  A.41c. 


3^0 


purchases,  and  travel  plans)  and  real-time  psychological  (peace  of  mind) 
benefits  to  members  and  their  families. 

♦  Carriers  who  declare  bankruptcy  often  leave  a  trail  of  frustrated  shipments, 
primarily  because  their  locations  are  unknown.  Although  ITV  could  miti¬ 
gate  the  impact  of  business  failures  and  bankruptcies  on  shipments,  such 
events  do  not  warrant  expanding  ITV  on  this  basis  alone. 

In  addition  to  alleviating  the  negative  impacts  of  these  two  conditions,  en¬ 
hanced  nV  of  personal  property  shipments  could  make  it  easier  for  DoD  trans¬ 
portation  personnel  and  commercial  carriers  to  divert  shipments;  determine  why 
shipment  deliveries  are  late;  and  reduce  storage  requirements  (and  storage  costs) 
at  destination. 


Enhancing  Current  ITV  Capabilities 

MTMC  and  the  Military  Services  could  increase  their  visibility  over  selected 
personal  property  shipments  easUy  and  inexpensively  by  taking  the  following 
action: 

Action:  USTRANSCOM,  MTMC,  and  Military  Services  require  carriers  to 
provide,  using  EDI  techniques,  shipment  status  messages  for  designated  ship¬ 
ments  upon  the  occurrence  of  specific  events: 

♦  For  international  shipments:  At  PPSO's  request,  when  ocean  transit  begins  and 
ends,  and  when  the  shipment  has  not  been,  or  cannot  be,  delivered  by  the 
required  delivery  date. 

♦  For  Blue  Bark  shipments:  Automatically,  upon  occurrence  of  any  or  all  of  the 
events  described  above. 

Figure  3-13  shows  the  concept  for  enhancing  DoD's  visibility  over  personal 
property  shipments.  For  carriers  that  are  EDI-capable,  PPSOs  would  use  the 
ASC  X12  213  Transaction  Set  to  trcinsmit  messages  requesting  shipment  status  in¬ 
formation.  The  Cctrriers,  in  turn,  would  use  the  ASC  X12  214  Transaction  Set  to 
transmit  shipment  status  messages  to  PPSOs.  For  non-EDI-capable  carriers,  the 
PPSOs  would  use  telephone  or  some  other  means  of  responsive,  time-sensitive 
communications  to  contact  the  carriers  and  receive  their  responses. 

This  concept  is  preferable  to  developing  an  electronic  link  between  the 
DoD's  personal  property  automated  systems  [i.e.,  the  multi-service  Transporta¬ 
tion  Operational  Personal  Property  Standard  System  (TOPS)  and  MTMC's 
Worldwide  Household  Goods  Information  System  for  Transportation  (WHIST)] 
and  GTN.  Unless  it  can  be  justified  on  the  basis  of  monetary  savings,  improved 
efficiency,  and  enhanced  customer  service,  that  link  is  neither  currently  envi¬ 
sioned  nor  warranted. 
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*  Blue  Bark  status  messages  to  be  provided  automatically  (without  PPSO's  request). 


Figure  3-13. 

Personal  Property  Shipments  —  Operating  Concept 
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Chapter  4 


Implementation  Priorities 
and  Schedules 

Introduction 

The  complexities  of  developing  a  worldwide  ITV  capability,  coupled  with 
the  realities  of  limited  financial  and  personnel  resources,  mandate  that  DoD  im¬ 
plement  its  nV  efforts  m  a  logical  manner.  The  priorities  for  implementation 
recommended  in  this  chapter  are  not,  however,  intended  to  suggest  a  rigid  im¬ 
plementation  sequence  (some  implementation  efforts  will  occur  simultaneously) 
or  the  relative  importance  of  one  functional  area  over  another.  Rather,  they  are 
meant  to  assist  in  the  allocation  of  scarce  resources. 

In  consonance  with  those  intentions,  this  chapter  presents  a  process  to  pri¬ 
oritize  the  six  functional  ITV  areas  of  unit  cargo,  non-unit  cargo,  unit  personnel, 
non-unit  personnel,  medical  patients,  and  personal  property  on  the  basis  of  their 
relative  benefits,  difficulties,  resources,  and  existing  capabilities.  It  also  presents 
implementation  schedules  for  the  functional  areas  based  on  these  four  considera¬ 
tions.  The  schedules  are  intended  to  provide  DoD  with  a  plan  for  coordinating 
implementation  activities  throughout  the  ITV  community.  As  such,  they  are 
subject  to  change  as  the  realities  of  implementation  unfold.  Therefore,  all  sched¬ 
ules  are  contingent  upon  the  planned  award  of  the  GTN  development  contract  in 
early  1995. 


Prioritization  Criteria  and  Rationale 

Implementing  the  proposed  ITV  operating  concepts  would  require  substan¬ 
tial  resources,  particularly  to  develop  and  enhance  the  application  systems. 
However,  the  responsible  organizations  —  USTRANSCOM,  TCCs,  Military  Serv¬ 
ices,  and  DLA  —  do  not  possess  the  required  funds  and  personnel  to  pursue  all 
six  fimctional  areas  simultaneously.  As  a  consequence,  DoD  should  allocate  its 
resources  initially  to  those  ITV  applications  that  provide  the  most  return  for  the 
least  cost.  In  making  those  allocations,  DoD  should  consider  four  criteria:  bene¬ 
fits,  difficulties,  resources,  and  existing  capabilities. 


Benefits 


The  primary  benefits  of  ITV  are  enhanced  warfighting  capability  and  re¬ 
duced  operating  costs.  The  enhanced  warfighting  capability  would  stem  from 
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the  DoD's  increased  ability  to  divert  and  reconstitute  shipments,  plan  transporta¬ 
tion  movements,  exercise  sound  traffic  management,  and  ensure  personnel  and 
materiel  reach  their  destination  in  a  timely  and  complete  manner.  The  lower  op¬ 
erating  costs  would  result  from  greater  efficiency  in  both  transportation  and  sup¬ 
ply  operations.  For  example,  knowing  the  status  and  location  of  a  shipment 
would  lessen  the  inclination  to  place  a  second  requisition  for  the  materiel  com¬ 
prising  the  shipment. 


Difficulties 


Although  rrV  offers  potentially  high  benefits,  other  technical  or  operational 
barriers  could  prevent  DoD  from  attaining  them.  For  instance,  poor  data  quality 
could  reduce  the  benefits  from  a  central  ITV  data  base  and  the  lack  of  assured 
communications  in  remote  theaters  could  restrict  ITV  of  cargo  and  personnel 
within  theaters.  These  and  other  barriers  are  likely  to  increase  the  risk  and  diffi¬ 
culty  of  implementing  ITV  for  many  years. 


Resources 


This  criterion  includes  the  resources  associated  with  making  the  needed  sys¬ 
tem  enhancements,  such  as  monetary  and  personnel  requirements  for  procuring 
hardware,  software,  or  communications;  developing  or  enhancing  application 
systems;  and  developing  system  interfaces.  Another  factor  that  needs  to  be  con¬ 
sidered  is  the  time  required  to  obtain  the  necessary  resources  and  field  the  objec¬ 
tive  systems. 


Existing  Capabilities 

This  last  criterion  recognizes  that  current  policies,  procedures,  and  auto¬ 
mated  systems  already  provide  the  Military  Services  and  DLA  with  varying  de¬ 
grees  of  ITV.  Such  existing  capabilities  must  be  considered  in  prioritizing  the  six 
functional  areas. 


Prioritization  and  Implementation  Schedules 

This  section  presents  the  results  of  applying  the  above  criteria  and  assigning 
high,  medium,  and  low  ratings  to  each  of  the  six  functional  areas  of  ITV.  Two 
examples  illustrate  that  application. 

♦  A  functional  area  that  offers  high  war  and  economic  benefits,  medium  im¬ 
plementation  difficulty,  and  low  resource  requirements  should  be  assigned 
a  high  priority  and  selected  as  a  near-term  ITV  initiative. 
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♦  A  functional  area  that  offers  low  benefits,  high  implementation  difficulty, 
and  high  resource  requirements  should  be  assigned  a  low  priority  and  not 
be  selected  for  early  implementation. 

The  prioritization  process  indicates  that  non-unit  cargo  and  unit  cargo  war¬ 
rant  the  highest  priority  application  of  implementation  resources.  Unit  person¬ 
nel,  medical  patients,  and  non-unit  personnel  warrant  lower  priorities,  while 
personal  property  is  assigned  the  lowest  priority.  The  evaluation  process  for 
each  of  the  six  ftmctional  areas  is  described  below. 


Cargo  —  Non-Unit 

Attaining  ITV  of  non-unit  cargo,  from  its  origin  to  a  POD  and  then  forward 
to  a  theater  destination,  is  a  high-priority  initiative.  It  would  provide  substantial 
wartime  benefits  because  critical  repair  items  and  other  sustaining  materiel  could 
be  tracked  while  enroute.  Experience  gained  during  Desert  Shield/ Storm  re¬ 
vealed  numerous  opportunities  to  reduce  port  bottlenecks  and  the  sustainment 
pipeline,  and  divert  enroute  shipments  to  new  destinations.  Considerable  eco¬ 
nomic  benefits  during  peacetime  would  also  accrue  from  knowing  the  status  of 
requisitioned  or  purchased  materiel  while  it  is  intransit,  such  as  reductions  in  in¬ 
ventory  levels. 

Those  benefits  do  not  come  free,  however.  The  complexity  of  interfaces  and 
variety  of  movement  data  sources  make  non-unit  cargo  ITV  both  a  technical  and 
operational  challenge.  However,  those  challenges  are  mostly  offset  by  the  sys¬ 
tem  capabilities  already  in  place,  which  greatly  reduces  the  resources  required  to 
accomplish  the  many  tasks  associated  with  ITV  of  non-unit  cargo.  In  order  to 
achieve  this  capability,  DoD  should  focus  on  developing  a  theater  transportation 
system  to  identify  and  track  non-unit  cargo,  and  on  capturing  CONUS  source 
data  through  increased  use  of  EDI  and  other  technologies. 

Figure  4-1  shows  the  schedule  for  implementing  22  major  non-unit  cargo 
ITV  initiatives.  These  22  initiatives  are  comprised  of  eight  programs,  one  for 
gaining  ITV  over  theater  movements  and  seven  for  capturing  data  from  CONUS 
source  systems. 

Before  DoD  can  have  ITV  over  theater  movements,  it  needs  to  develop  a 
theater  transportation  system  and  then  interface  it  with  GTN.  While  these  ac¬ 
tions  are  vital  to  ITV,  the  theater  transportation  system  cannot  be  developed  be¬ 
fore  the  end  of  the  fourth  quarter  of  1997.  Interfaces  between  that  system  and 
GTN,  WPS,  CAPS  n,  and  coirunercial  foreign  carriers  would  then  be  completed 
by  the  end  of  the  second  quarter  of  1999. 
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Task 

Start/end  date 

Pgref 

Schedule® 

1995 

1996 

1997 

1998 

1999 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Develop  theater  system 

1Q95-4Q97 

C-2 

— 

— 

— 

— 

Interface  GTN  -  theater  system 

2Q97-1Q98 

C-10 

- 

_ 

— 

Interface  GTN  -  DAMMS-R 

2Q96-1Q97 

C-10 

— 

— 

- 

Interface  WPS  -  theater  system 

1Q98-4Q98 

C-12 

— 

— 

Interface  CAPS  II  -  theater  system 

3Q98-2Q99 

C-12 

— 

— 

Interface  theater  system  - 
commercial  foreign  carriers 

1Q98-4Q98 

C-12 

■ 

■ 

■ 

— 

— 

interface  GTN-GDSSb 

1Q95 

C-10 

▲ 

Interface  GTN  -  DAASb 

1Q95 

C-10 

▲ 

Interface  GTN  -  ICS 

3Q97-2Q98 

C-10 

— 

— 

Interface  GTN-CFMc 

4Q95-1Q97 

C-10 

- 

— 

— 

Implement  EDI  for  GBLs 

1Q94-2Q95 

C-23 

— 

Enhance  GTN  -  WPS  interface  b 

4Q96  -  3Q97 

C-10 

— 

— 

— 

Enhance  GTN  -  CAPS  II  interface  e 

2Q97-1Q98 

C-10 

— 

Implement  EDI  for  vendor 
shipments 

1Q95-1Q97 

C-18 

— 

— 

— 

— 

— 

Implement  EDI  for  ordnance  data 

1Q94-2Q95 

C-14 

_ 

Interface  GTN  -  DTTS 

3Q97-2Q98 

C-10 

— 

DTTS  mode  expansion 

3Q94  -  3Q96 

C-14 

— 

— 

— 

— 

Capture  ordnance  non-EDI  data 

3Q94  -  3Q96 

C-14 

Implement  EDI  for  CBLs 

1Q95-2Q96 

C-27 

HI 

^1 

Implement  EDI  for  carrier  status 
data 

Capture  enhanced  MILSTAMP  data 

1Q95-4Q95 

1Q95-2Q97 

C-31 

C-39 

— 

— 

Interface  GTN  -  postal  system 

2Q98-1Q99 

C-10 

^^1 

■1 

■Mil 

■1 

^^1 

■1 

— i. 

- 

Note:  ICS  =  Integrated  Command,  Control,  and  Communications  System. 

"Month  in  schedule  columns  indicates  a  six-month  period  beginning  with  that  month. 

"This  interface  exists  in  the  GTN  prototype;  it  will  also  be  required  in  the  new  GTN  contract. 

'Includes  GBL,  vendor,  CBL,  and  carrier-status  data. 

"An  interface  with  the  GTN  prototype  already  exists.  In  this  task,  the  capabilities  of  that  interface  will  be  expanded  to  Include 
vendor,  carrier  status,  and  enhanced  MILSTAMP  data. 

'An  interface  with  the  GTN  prototype  already  exists.  In  this  task,  the  capabilities  of  that  interface  will  be  expanded  to  include 
vendor  and  enhanced  MILSTAMP  data. 

Figure  4-1. 

Cargo  —  Non-Unit  Movements  Implementation  Schedule 
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The  seven  CONUS  source  data  capture  programs  will  incrementally  increase 

DoD's  visibility  over  non-unit  shipments  moving  from  CONUS  sources  to  ports 

or  CONUS  destinations.  Summaries  of  those  programs  are  provided  below: 

♦  GBL.  In  January  1994,  MTMC  implemented  at  a  few  Defense  shipping  ac¬ 
tivities  an  EDI  program  to  capture  GBL  data  for  pa5Tnent  applications. 
Eventually,  that  capability  will  exist  at  600  CONUS  shipping  activities.  In 
order  to  use  that  data  for  ITV,  the  DoD  needs  to  develop  an  interface  be¬ 
tween  GTN  and  the  CFM  system.  That  interface  is  scheduled  for  completion 
by  the  end  of  the  first  quarter  of  1997. 

♦  Vendor.  About  one-third  of  all  non-unit  cargo  originates  at  commercial  ven¬ 
dors.  As  a  result,  visibility  over  that  cargo  is  a  key  priority  in  the  implemen¬ 
tation  schedule.  However,  it  is  also  difficult  to  achieve.  DoD  needs  to  first 
finalize  an  operating  concept  for  capturing  vendor  data,  and  then  modify  its 
procurement  regulations,  policies,  and  procedures  in  accordance  with  that 
concept.  It  also  needs  to  develop  an  EDI  program  for  capturing  vendor 
shipment  information.  Finally,  USTRANSCOM  needs  to  establish  interfaces 
between  GTN  and  the  CFM  system,  WPS,  and  CAPS  II  for  exchanging  ven¬ 
dor  information.  These  activities  are  targeted  for  completion  by  the  end  of 
the  first  quarter  of  1998. 

♦  Ordnance.  DTTS  currently  captures  ordnance  shipment  information  for  mo¬ 
tor  shipments  and  tracks  those  shipments  using  satellite  technology.  The 
DTTS  Program  Office  needs  to  expand  the  system's  tracking  capabilities  to 
include  all  modes  of  transportation  within  CONUS  and  to  OCONUS  desti¬ 
nations.  It  also  needs  to  add  an  EDI  capability  for  capturing  ordnance  ship¬ 
ment  information  from  EDI-capable  shippers,  and  other  automated  data 
collection  capabilities  for  use  with  non-EDI-capable  shipping  activities.  Fi¬ 
nally,  the  Program  Office  needs  to  establish  an  interface  between  DTTS  and 
GTN.  These  activities  are  scheduled  for  completion  by  the  second  quarter  of 
1998. 

♦  CBL.  USTRANSCOM  needs  to  implement  a  program  for  capturing  CBL 
data  by  using  the  same  EDI  infrastructure  established  for  capturing  GBL 
data.  Before  this  program  can  be  implemented,  however,  the  DoD  needs  to 
enhance  its  EDI  implementation  guidelines  and  develop  new  operating  pro¬ 
cedures.  Defense  shipping  activities  then  need  to  modify  their  EDI  systems 
to  transmit  CBL  data  to  the  CFM  system.  Finally,  the  interface  between  the 
CFM  system  and  GTN  needs  to  be  enhanced  to  include  CBL  data.  These  ac¬ 
tions  are  targeted  for  completion  by  the  first  quarter  of  1997. 

♦  Carrier  status.  In  addition  to  receiving  shipment  information  for  all  non-unit 
cargo  shipments,  GTN  will  receive  EDI-based  carrier  status  messages  from 
the  CFM  system  and  WTS  on  the  location  and  condition  of  shipments  imder 
a  commercial  carrier's  control.  This  application  is  widely  used  in  commer¬ 
cial  industry.  To  achieve  such  a  capability,  MTMC  needs  to  augment  the 
EDI  capabilities  of  the  CFM  system  and  WTC  to  receive  and  process  carrier 
status  messages.  It  also  needs  to  enhance  the  interfaces  of  those  systems 
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with  GTN.  These  activities  are  targeted  for  completion  by  the  end  of  the 
third  quarter  of  1997. 


♦  MILSTAMP.  WhUe  GTN  currently  receives  MILSTAMP  data  for  shipments 
moving  between  POE  and  POD,  the  quality  of  that  data  is  inadequate  and 
compliance  is  inconsistent.  In  spite  of  those  data  shortcomings,  GTN  needs 
to  modify  MILSTAMP  to  capture  additional  data,  including  source  to  POE 
data.  DoD  also  needs  to  improve  the  quality  and  timeliness  of  MILSTAMP 
data,  with  the  use  of  EDI  offering  some  improvement.  Finally, 
USTRANSCOM  needs  to  enhance  the  existing  GTN  interfaces  with  WPS  and 
CAPS  II  to  include  the  additional  MILSTAMP  data.  These  activities  are 
scheduled  for  completion  by  the  end  of  the  first  quarter  of  1998. 

♦  Mail.  While  still  an  ITV  requirement,  the  capture  of  mail  data  is  viewed  as  a 
low  priority  because  of  its  marginal  return  and  the  absence  of  systems  for 
providing  ITV  data.  However,  when  the  USPS  develops  a  system  that  can 
provide  GTN  with  mail  shipment  information,  USTRANSCOM  needs  to  de¬ 
velop  an  interface  between  GTN  and  that  system.  These  actions  are  not 
likely  to  occur  before  the  end  of  the  first  quarter  of  1999. 

Cargo  —  Unit 

Intransit  visibility  of  imit  cargo  is  also  a  high  priority.  Providing  the  status 
of  unit  cargo  movements  to  warfighting  CINCs  would  give  them  the  capability 
to  balance  force  closures  with  operational  requirements.  However,  the  economic 
benefits  of  unit  cargo  visibility  are  less  than  those  for  other  functional  areas,  par¬ 
ticularly  non-unit  cargo.  The  existence  and  ongoing  development  of  various  unit 
movement  planning  and  tracking  systems,  such  as  JOPES,  GTN,  GCCS, 
TC  AIMS,  CAPS  II,  and  WPS,  reduce  the  difficulties  and  resource  demands  asso¬ 
ciated  with  attaining  ITV  over  unit  cargo. 

Figure  4-2  shows  the  schedule  for  developing  ITV  over  unit  cargo  move¬ 
ments.  The  primary  actions  are  the  development  of  system  interfaces  and  the  de¬ 
velopment  of  a  theater  transportation  system.  In  addition,  many  of  the  non-unit 
cargo  source  data  capture  programs  also  apply  to  unit  cargo.  The  implementa¬ 
tion  timelines  are  dependent  upon  the  completion  of  the  theater  transportation 
system  by  the  end  of  the  fourth  quarter  of  1997.  In  the  interim,  USTRANSCOM 
should  develop  interfaces  between  GTN  and  ST  ACCS,  DAMMS-R,  and  deployed 
TC  AIMS,  to  achieve  some  theater  ITV  capability. 
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Task 

pg 

ref 

Start/end 

date 

Schedule^ 

1995 

1996 

1997 

1998 

1999 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Interface  GTN  -  TC  AIMS 

C-10 

3095  -  2096 

Develop  theater  system 

C-2 

1095-4097 

Interface  GTN  -  theater 
system 

C-10 

2097-1098 

— 

— 

— 

Interface  theater  system  - 
commercial  foreign  canters 

C-12 

1098  -  4098 

Interface  GTN  -  STACCS 

C-10 

4096  -  3097 

— 

— 

- 

Interface  WPS  -  theater 
system 

C-12 

1098-4098 

Interface  CAPS  II  -  theater 
system 

C-12 

3098-2099 

Interface  TC  AIMS  -  CAPS  11 

C-12 

1096-4096 

Interface  TC  AIMS  -  CFM 

C-12 

1095  -  2095 

Interface  TC  AIMS -WPS 

C-12 

1097  -  4097 

Interface  TC  AIMS  -  TCAIMS 

C-12 

3096-2097 

Interface  CFM  system  -  GTNi^ 

C-10 

4095-1097 

Enhance  GTN  -  WPS 
Interface*^ 

C-10 

4096  -  3097 

- 

- 

Enhance  GTN  -  CAPS  II 
Interface‘s 

C-10 

2097-1098 

- 

— 

- 

Interface  GTN  —  GOSS 

C-10 

1095 

▲ 

Interface  GTN-DAMMS-R 

C-10 

2096-1097 

— 

- 

Interface  GTN  -  ICS 

c-10 

3097  -  2098 

‘Month  in  schedule  columns  indicates  a  six-month  period  beginning  with  that  month. 

‘An  interface  with  the  GTN  prototype  already  exists.  In  this  task,  its  capabilities  will  be  expanded. 
‘This  interface  exists  in  the  GTN  prototype;  it  will  also  be  required  in  the  new  GTN  contract. 


Figure  4-2. 

Cargo  —  Unit  Movements  Implementation  Schedule 


Personnel  —  Unit 

Visibility  over  unit  personnel  movements  would  improve  DoD's  ability  to 
rapidly  project  forces  and  enhance  its  ability  to  provide  planning  information  to 
theater  CINCs.  Although  most  ITV  of  unit  persormel  is  currently  obtained 
through  slow  and  cumbersome  manual  data  entry  and  manifest  preparation  pro¬ 
cedures,  AMC  and  the  Military  Services  have  expended  considerable  resources 
to  automate  the  collection  and  processing  of  personnel  information.  Both  AMCs 
CAPS  II  and  the  Military  Services'  TC  AIMSs  will  be  capable  of  producing  auto¬ 
mated  passenger  manifests.  Those  systems  will  initially  provide  ITV  of  person¬ 
nel  within  overseas  theaters,  but  eventually  DoD  will  need  to  encompass  aU 
tracking  of  unit  personnel  in  overseas  theaters  under  one  system. 

Figure  4-3  shows  the  implementation  schedule  for  unit  personnel  move¬ 
ments.  USTRANSCOM  plans  to  interface  the  various  TC  AIMSs  with  GTN  by 
the  end  of  the  second  quarter  of  1996.  Since  CAPS  II  is  in  the  process  of  being 
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fielded,  AMC  and  the  Military  Services  need  to  build  interfaces  between  that  sys¬ 
tem  and  the  TC  AIMSs  to  provide  ITV  over  unit  personnel  deploying  via  air  by 
the  end  of  the  fourth  quarter  of  1996.  Development  of  an  interface  between  WPS 
and  the  TC  AIMSs  by  the  end  of  the  fourth  quarter  of  1997  would  provide  simi¬ 
lar  visibility  over  units  deploying  via  sealift.  In  the  interim,  the  CAPS  II  and 
TC  AIMSs  will  be  capable  of  providing  ITV  over  units  moving  in  overseas  thea¬ 
ters  until  the  theater  transportation  system  is  developed  by  the  end  of  the  fourth 
quarter  of  1997.  Finally,  completing  the  development  of  SAIMD  will  improve 
the  timeliness  and  accuracy  of  unit  personnel  data. 


Schedule^ 


Task 

Pg 

ref 

Start/end  date 

1995 

1996 

1997 

1998 

1999 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Interface  GTN  -  TC  AIMS 

C-10 

3Q95  -  2Q96 

— 

— 

Interface  TC  AIMS  -  CAPS  II 

C-12 

1Q96-4Q96 

— «■ 

SAIMD  development 

C-36 

1Q95-3Q96 

— 

^5 

— 

Interface  TC  AIMS  -  TC  AIMS 

C-12 

3Q96  -  2Q97 

— 

— I- 

Interface  TC  AIMS -WPS 

C-12 

1Q97-4Q97 

— 

^5 

Develop  theater  system 

C-2 

1Q95-4Q97 

252 

52S 

22 

Interface  GTN  -  theater 

C-10 

2Q97-1Q98 

■ 

■H 

■ 

m 

m 

■ 

■ 

■ 

system 

■ 

■ 

■ 

E 

mm 

■ 

■ 

■ 

Interface  WPS  -  theater 

C-12 

1Q98-4Q98 

system 

Interface  CAPS  II  -  theater 

C-12 

3Q98  -  2Q99 

system 

Interface  GTN  -  GDSS  b 

C-10 

1Q95 

▲ 

Enhance  GTN  -  WPS  c 

C-10 

4Q96  -  3Q97 

I 

n 

■ 

I 

■ 

IntGrfac© 

Interface  GTN  -  PRAMS  b 

C-10 

1Q95 

▲ 

“Month  in  schedule  columns  indicates  a  six-month  period  beginning  with  that  month. 

“This  interface  exists  in  the  GTN  prototype;  it  will  also  be  required  in  the  new  GTN  contract. 

“An  interface  with  the  GTN  prototype  already  exists.  In  this  task,  its  capabilities  will  be  expanded. 


Figure  4-3. 

Personnel  —  Unit  Movements  Implementation  Schedule 


Personnel  —  Medical  Patients 

The  visibility  of  patients  undergoing  aeromedical  evacuation  is  essential 
during  both  peace  and  war.  In  peacetime,  patient  movement  visibility  also  satis¬ 
fies  the  DoD's  and  public's  demand  for  timely  and  accurate  casualty  reporting,  a 
demand  that  has  been  strongly  influenced  by  extensive  media  coverage  and  in¬ 
stantaneous  news  reporting.  During  wartime,  rapid  casualty  movement  through 
an  efficient  aeromedical  evacuation  system  enhances  warfighting  capabilities. 


4-8 


Ciirrent  procedures  for  the  movement  of  patients  from  origin  to  a  destina¬ 
tion  MTF  are  neither  fully  automated  nor  integrated.  The  USTRANSCOM's  Sur¬ 
geon  is  developing  TRAC2ES  to  overcome  many  of  the  existing  shortcomings. 
Figure  4-4  shows  the  schedule  for  completing  TRAC2ES.  The  test  and  evaluation 
of  an  operational  prototype  of  TRAC2ES  is  scheduled  for  July  1994.  If  the  test 
and  eviuation  is  successful,  TRAC2ES  should  be  fielded  by  the  third  quarter  of 
1997.  The  other  major  activity  in  the  implementation  of  ITV  capability  for  pa¬ 
tient  movements  is  the  development  of  a  standard  MARC. 


Task 

Pg 

ref 

Start/end  date 

Schedule® 

1993 

1994 

1995 

1996 

1997 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Develop  TRAC2ES 

C-6 

1Q93-3Q97 

— 

■H 

MARC  development 

C-36 

2Q94  -3Q95 

■ 

■ 

■ 

■ 

■ 

■ 

K 

B 

•  Month  in  schedule  column  indicates  a  six-month  period  beginning  with  that  month. 


Figure  4-4. 

Personnel  —  Medical  Patients  Implementation  Schedule 


Personnel  —  Non-Unit 

During  Desert  Shield/ Storm,  a  lack  of  visibHity  of  non-unit  personnel  move¬ 
ments  hampered  the  DoD's  ability  to  track  replacements  once  they  departed  an 
APOE.  It  ^so  inhibited  the  forecasting  of  onward  movement  requirements  once 
replacement  and  filler  personnel  arrived  in  theater. 

The  current  processing  of  non-unit  personnel  by  PRAMS  provides  the  trans¬ 
portation  community  with  some  movement  visibility  information.  Although 
PRAMS  is  already  interfaced  to  GTN,  it  is  not  linked  to  the  Military  Services' 
personnel  systems.  That  shortcoming  may  require  considerable  resources  to 
overcome. 

Figure  4-5  shows  the  schedule  for  implementing  ITV  over  non-unit  person¬ 
nel  movements.  Since  a  PRAMS  interface  with  GTN  is  already  complete, 
USTRANSCOM  has  some  ITV  of  non-unit  personnel  moving  on  organic  trans¬ 
portation.  The  remaining  actions  focus  on  developing  PRAMS  interfaces  with 
commercial  reservations  systems  and  Military  Service  personnel  systems.  AMC 
is  already  building  interfaces  with  the  commercial  reservations  systems,  while 
the  interfaces  with  the  Military  Service  personnel  systems  should  be  completed 
by  the  second  quarter  of  1996.  PRAMS  and  CAPS  II  are  fielded  at  some  theater 
locations;  ultimately,  fielding  should  be  expanded  and  integrated  so  that  PRAMS 
functions  as  the  standard  theater  system.  Building  an  interface  between  PRAMS 
and  TRAC2ES,  although  not  a  complicated  process,  will  not  be  completed  until 
late  in  the  TRAC2ES  development  process. 
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Task 

Pg 

ref 

Start/end  date 

Schedule® 

1994 

1995 

1996 

1997 

1998 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Interface  PRAMS  -  Military 
Service  personnel  systems 

C-12 

2Q94  -  2Q96 

Interface  PRAMS  -  commercial 
reservations  systems 

C-12 

3Q94  -2Q95 

Interface  TRAC2ES  -  PRAMS 

C-12 

1Q98-4Q98 

Interface  GTN  -  theater  system 

C-10 

2Q97-1Q98 

■ 

31 

Interface  GTN  -  PRAMS 

C-10 

1Q95 

Interface  CTN-GOSS*^ 

C-10 

1Q95 

"Month  in  schedule  columns  indicates  a  six-month  period  beginning  with  that  month. 

"An  interface  with  the  GTN  prototype  already  exists;  it  will  also  be  required  in  the  new  GTN  contract. 


Figure  4-5. 

Personnel  —  Non-Unit  Movements  Implementation  Schedule 


Cargo  —  Personal  Property 

Intransit  visibility  over  personal  property  shipments  has  the  lowest  priority 
because  it  does  not  contribute  to  a  CINC's  warfighting  capability  and  it  provides 
few  economic  benefits.  In  addition,  existing  policies  and  procedures  already 
provide  a  reasonable  degree  of  ITV. 

Increasing  ITV  beyond  that  already  available  could  be  achieved  by  requiring 
carriers  to  provide  PPSOs  with  international  shipment  information  at  critical 
transit  nodes,  such  as  the  onset  and  termination  of  ocean  transit  and  non¬ 
delivery  by  the  RDD.  The  status  updates,  if  provided  electronically,  would  be 
relatively  easy  to  initiate.  These  new  requirements  could  be  readily  incorporated 
into  existing  personal  property  docmnentation,  such  as  the  PPTMR  and  Tender 
of  Service. 

Figure  4-6  shows  the  implementation  schedule  for  developing  such  a  capa¬ 
bility.  The  process  of  implementing  electronic  status  messages  for  selected  types 
or  categories  of  personal  property  shipments  is  not  linked  to  the  GTN  and  other 
systems  interface  efforts.  The  implementation  process  could  therefore  begin  con¬ 
currently  with  other  ITV-related  system  development  and  interface  tasks. 
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a 

Schedule 

Task 

Pg 

ref 

Start/end  date 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Implement  EDI  for  carrier 
status  data 

C-44 

1Q95-2Q96 

■Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  4-6. 

Cargo  —  Personal  Property  Implementation  Schedule 


Summary 


The  DoD  should  give  the  highest  priority  to  developing  ITV  for  non-unit 
and  tmit  cargo,  followed  in  turn  by  unit  personnel,  medical  patients,  and  non¬ 
unit  personnel.  Personal  property  has  the  lowest  priority.  However,  the  multi¬ 
tude  of  tasks,  and  the  urgent  need  for  ITV  for  each  functional  area,  makes  a  rigid 
approach  to  implementing  ITV  impractical. 

The  tasks  identified  for  accomplishment  within  each  of  the  six  functional  ar¬ 
eas  fall  into  four  major  categories  —  GTN  system  interfaces,  other  system  inter¬ 
faces,  source  data  capture,  and  system  development.  Some  of  the  tasks  in  those 
categories  pertain  to  more  than  one  fimctional  area,  which  introduces  the  pros¬ 
pect  of  some  synergy  among  the  ITV  tasks.  Table  4-1  shows  the  relationships 
among  the  four  categories  and  tasks  by  functional  areas.  Appendix  C  presents 
detailed  implementation  plans  and  schedules  that  substantiate  the  timelines 
shown  in  this  chapter. 
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Table  4-1. 

Functional  Program  Tasks 


Interface  GTN  —  theater  system 


Interface  GTN  —  STAGGS 


Interface  GTN  —  DAMMS-R 


Interface  GTN  —  GFM 


Enhance  GTN  —  WPS  interface 


Enhance  GTN  —  GAPS  II  interface 


Interface  GTN  —  DTTS 


Interface  GTN  —  postal  system 


Interface  GTN  —  GDSS 


Interface  GTN  —  PRAMS 


Interface  GTN  —  DAAS 


Interface  GTN  —  IG3 


Interface  TRAG2ES  —  PRAMS 


Other  interfaces 


Interface  WPS  —  theater  system 


Interface  GAPS  II  — theater  system 


Interface  TG  AIMS  —  GAPS  II 


Interface  TG  AIMS  —  GFM 


Interface  TG  AIMS  —  WPS 


Interface  TG  AIMS  —  TG  AIMS 


Interface  theater  system  — 
commercial  foreign  carriers 
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Table  4-1. 

Functional  Program  Tasks  (continued) 


Interface  PRAMS  —  Military  Service 
personnei  systems 

H 

Interface  PRAMS  —  commercial 
reservations  systems 

H 

Source  data  capture  programs 


implement  EDI  for  GBLs 

X 

X 

Implement  EDI  for  vendor  shipments 

X 

Implement  EDI  for  ordnance  data 

X 

X 

DTTS  mode  expansion 

wm 

X 

Capture  ordnance  non-EDi  data 

wm 

X 

Implement  EDI  for  CBLs 

Implement  EDI  for  carrier  status  data 

X 

Hi 

X 

Capture  enhanced  MiLSTAMP  data 

mm 

X 

SAIMD  card  deveiopment 

X 
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Personnel  —  Medical  Patients 
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Appendix  A 

System  Descriptions 


This  appendix  describes  a  number  of  systems  that  contribute  to  the  Depart¬ 
ment  of  Defense's  intransit  visibility  (ITV)  system.  The  office  or  organization 
identified  in  brackets  is  the  system  developer. 

ADAM  III  =  Aerial  Port  Documentation  and  Management  System  [AMC] 

Provides  real-time  automatic  data  processing  in  support  of 
cargo  and  mail  documentation  and  management. 

ADANS  =  Airlift  Deployment  Analysis  System  [AMC] 

Prepares  movement  tables  and  schedules  for  operation  plans, 
operations  orders,  channel  requirements,  and  tanker  sched¬ 
ules.  It  assists  in  transportation  feasibility  analyses. 

AFLIF  =  Air  Force  Logistics  Information  File  [AFMC] 

Provides  some  ITV  for  the  Air  Force  by  integrating  supply  and 
transportation  information.  The  system  can  be  queried  by  req¬ 
uisition  number,  transportation  control  number,  or  national 
stock  number.  It  provides  management  and  performance  re¬ 
ports.  AFLIF's  carrier  status  electronic  data  interchange  (EDI) 
program  with  FedEx  and  UPS  will  be  incorporated  into  the 
CONUS  Freight  Management  (CFM)  system. 

APACCS  =  Aerial  Port  Automated  Command  and  Control  System  [AMC] 

A  new  system  that  will  automate  the  air  terminal  operatioris 
center  and  its  associated  work  centers  at  Air  Mobility  Com¬ 
mand  (AMC)  aerial  ports.  It  will  also  provide  real-time  airlift 
information  on  cargo  and  passengers  via  an  interface  with  the 
Command  and  Control  Information  Processing  System. 


A-1 


APES 


Automated  Patient  Evacuation  System  [AMC] 


ASPUR 


C2IPS 


CAEMS 


CAPS 


Automates  the  processes  involved  in  transporting  patients  to 
medical  treatment  facilities  worldwide.  It  includes  automated 
patient  manifesting,  itinerary  and  mission  planning,  manage¬ 
ment  reporting,  and  inter-agency  communication.  It  interfaces 
with  the  Defense  Medical  Regulating  Information  System. 
The  system  will  migrate  to  the  TRANSCOM  Command  and 
Control  Evacuation  System  (TRAC2ES). 

=  Automated  System  for  Processing  Unit  Requirements  [MTMC] 

Used  in  the  sea  deployment  process,  it  receives  unit  move¬ 
ment  requirements  from  Transportation  Coordinator's  Auto¬ 
mated  Command  and  Control  Information  System 
(TCACCIS),  processes  those  requirements,  sends  the  move¬ 
ment  release  to  the  installation  transportation  office,  and  cre¬ 
ates  advanced  Transportation  Control  and  Movement 
Documents  (TCMDs)  for  the  Terminal  Management  System 
(TERMS).  It  is  a  legacy  system  that  the  Integrated  Booking 
System  (IBS)  will  eventually  replace. 

=  Command  and  Control  Information  Processing  System  [AMC] 

A  new  system  that  will  enable  AMC  organizations  to  ex¬ 
change  information  between  the  operation,  logistics,  transpor¬ 
tation,  and  intelligence  functional  areas.  It  will  be  a  single, 
integrated  computer  system  to  aid  the  command  and  control 
activities  in  theater. 

=  Computer-Aided  Embarkation  Management  System  [USMC] 

Assists  Marine  Corps  personnel  in  planning,  documenting, 
and  executing  amphibious.  Marine  Prepositioned  Force,  and 
commercial  load  plans.  It  supports  tactical  and  administrative 
loading  and  provides  advanced  artificial  intelligence  capabili¬ 
ties  to  assist  planners  in  making  accurate  and  efficient  stowage 
decisions. 

=  Consolidated  Aerial  Port  Subsystems  [AMC] 

A  collection  of  systems  that  includes  the  ADAM  III  and  Pas¬ 
senger  Automated  Check-in  System  (PACS).  Provides  AMC 
with  a  standardized,  worldwide  automated  network  of  com¬ 
puters  to  process  cargo  and  passengers  moving  through  major 
aerial  ports.  CAPS  information  is  also  used  to  facilitate  accu¬ 
rate  and  timely  billing.  It  is  being  replaced  by  CAPS  II. 
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CAPS  II 


Consolidated  Aerial  Port  System  II  [AMC] 


CFM 


CHCS 


CMOS 


CRS 


DAAS 


A  real-time,  minicomputer-based  system  used  at  aerial  ports 
to  carry  out  local  cargo,  mail,  and  passenger  processing  func¬ 
tions.  It  operates  through  a  dedicated  circuit  to  Headquarters 
Cargo  System  (HCS)  computers.  This  system  permits  review 
and  evaluation  of  cargo  and  passenger  movements  on  a  real¬ 
time  basis.  It  includes  the  Aerial  Port  Documentation  and 
Management  System  (ADAM  III)  that  supports  cargo  ship¬ 
ments  and  the  Passenger  Automated  Check-In  System  (PACS) 
that  tracks  passengers. 

=  CONUS  Freight  Management  [MTMC] 

Provides  support  to  DoD  transportation  processing  and  plan¬ 
ning  through  interfaces  with  Defense  transportation  and  com¬ 
mercial  transportation  systems.  It  automates  shipment 
planning  and  docximent  preparation.  Through  the  use  of  EDI 
techniques,  it  exchanges  shipment  information  with  users 
from  transportation  offices,  carriers,  and  the  Defense  Finance 
and  Accounting  Service. 

=  Composite  Health  Care  System  [ASD(HA)] 

Provides  automated  support  to  medical  treatment  facilities 
worldwide.  Its  fimctions  include  scheduling  patient  appoint¬ 
ments,  and  providing  automated  administrative  support  for 
radiology,  pharmacy,  laboratory,  other  ancillaries,  outpatient 
clinical  services,  nursing,  and  o&er  inpatient  clinical  services. 

=  Cargo  Movement  Operations  System  [USAF] 

The  Air  Force's  Transportation  Coordinator's  Automated  In¬ 
formation  for  Movement  System  (TC  AIMS)  system  that  auto¬ 
mates  base  level  cargo  movement  processes  and  provides 
transportation  movement  officers  with  current  unit  movement 
data. 

=  Commercial  Reservation  Systems  [commercial  industry] 

A  generic  reference  to  the  commercial  airline  reservation  sys¬ 
tems. 

=  Defense  Automatic  Addressing  System  [DLA] 

Records  MILSTRIP  and  other  transactions  and  routes  them 
among  DoD  activities. 
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DAMMS-R 


DASPS-E 


DCAPS 


DMRIS 


DSOATS 


DSS 


=  Department  of  the  Army  Movements  Management 
System  —  Redesigned  [USA] 

Provides  transportation  information  to  movements  managers, 
highway  regulators,  and  mode  operators.  It  consists  of  seven 
interrelated  subsystems:  shipment  management,  movement 
control  team  operations,  mode  operations,  addressing,  high¬ 
way  regulation,  convoy  planning,  and  movement  program¬ 
ming. 

=  Department  of  Army  Standard  Port  System-Enhanced  [USA] 

Records  cargo  arrival,  staging,  and  outloading  information  for 
OCONUS  ports.  It  will  be  replaced  by  the  Worldwide  Port 
System  (WPS). 

=  Deployable  Consolidated  Aerial  Port  System  [AMC] 

Duplicates  the  ftmctions  of  CAPS  II  cargo  and  passenger  ap¬ 
plications  at  remote  sites  (both  CONUS  and  overseas).  It  con¬ 
sists  of  two  independent  software  applications  for  cargo  and 
passenger  operations  and  is  located  at  air  terminals  without 
sufficient  traffic  to  justify  a  CAPS  II  system  and  at  deployed 
air  terminals/ aerial  ports. 

=  Defense  Medical  Regulating  Information  System 
[ASD(AH)/USTRANSCOM/theater  CINCs] 

Tracks  requests  for  patient  beds  and  inter-hospital  airlift  trans¬ 
fer  requirements,  and  maintains  clinical  and  demographic  pa¬ 
tient  information.  It  will  be  integrated  with  APES  and  migrate 
to  TRAC2ES. 

=  Defense  Subsistence  Office  Automated  Transportation  System 
[DLA] 

Automates  and  prints  Government  bills  of  lading  (GBLs),  cal¬ 
culates  freight  charges,  and  provides  management  informa¬ 
tion  reports. 

=  Distribution  Standard  System  [DLA] 

The  Corporate  Information  Management  (CIM)  migration  sys¬ 
tem  that  wiU  replace  many  existing  distribution  legacy  sys¬ 
tems.  Those  legacy  systems  include  the  Defense  Logistics 
Agency's  (DLA's)  Defense  Warehousing  and  Shipping  Proce¬ 
dures  (DWASP)  and  Army's  Supply  Depot  System  (SDS).  It  is 
currently  being  developed  and  fielded. 
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DTTS 


Defense  Transportation  Tracking  System  [DoD/USN/MTMC] 


DWASP 


ETADS 


FLOWCAP 


GCCS 


GDSS 


Monitors  all  intra-CONUS  arms,  ammunition,  and  explosives 
shipments  moving  by  truck.  It  performs  this  task  using  a  com¬ 
mercial  satellite  tracking  surveillance  service,  which  provides 
DTTS  with  hourly  truck  location  reports,  intransit  truck  status 
changes,  and  emergency  situation  notifications. 

=  Defense  Warehousing  and  Shipping  Procedures  [DLA] 

Provides  automated  processing  and  documenting  capability 
for  line  items  from  receipt  of  material  at  depots  through  pack¬ 
ing  and  shipping.  It  will  be  replaced  by  DSS. 

=  Enhanced  Transportation  Automated  Data  System  [USAF] 

An  on-line,  integrated  system  that  assists  in  managing  and 
controlling  Air  Force  Materiel  Command  CONUS  transporta¬ 
tion  systems,  monitors  the  movement  of  Air  Force  cargo  over¬ 
seas,  and  manages  Air  Force  Transportation  ftmds. 

=  Non-unit  Related  Personnel  Flow  Computer  Assisted  Program 
[USA] 

A  dBASE  III  application  that  schedules,  controls,  and  tracks 
the  flow  of  individual  filler  and  casualty  replacement  person¬ 
nel  from  CONUS  replacement  centers,  through  aerial  ports  of 
embarkation,  to  the  theater  of  operations. 

=  Global  Command  and  Control  System  [JCS] 

A  future  replacement  system  for  the  Joint  Operations  Planning 
and  Execution  System  0OPES);  it  will  use  an  open  systems  ar¬ 
chitecture. 

Global  Decision  Support  System  [AMC] 

An  AMC  system  that  records  and  displays  airlift  schedules, 
aircraft  arrivals  and  departures,  and  limited  aircraft  status.  It 
provides  executive-level  decision  support. 
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HCS 


HOST 


IBS 


IC3 


IVIPS 


=  Global  Transportation  Network  [USTRANSCOM] 

Provides  the  automated  support  that  USTRANSCOM  and  its 
components  need  to  carryout  their  global  transportation  man¬ 
agement  responsibilities.  It  provides  the  integrated  transpor¬ 
tation  data  necessary  to  accomplish  transportation  planning, 
command  and  control,  patient  movement,  and  intransit  visi¬ 
bility  of  units,  passengers,  and  cargo  during  peace  and  war. 

=  Headquarters  Cargo  System  [AMC] 

This  system,  formally  named  Headquarters  On-Line  System 
for  Transportation  (HOST),  is  comprised  of  six  subsystems 
and  contains  airlift  cargo  data,  worldwide  manifest  data,  and 
air  shipment  information.  It  interfaces  with  the  Military  Serv¬ 
ice  air  clearance  authorities  and  with  GTN.  It  provides  a  cen¬ 
tralized  record  of  on-hand  cargo  and  cargo  movements  to 
AMC. 

=  Headquarters  On-line  System  for  Transportation  [AMC] 

See  HCS. 

=  Integrated  Booking  System  [MTMC] 

A  new  traffic  management  system  at  Military  Traffic  Manage¬ 
ment  Command  area  commands  that  will  register  cargo  for 
sealift,  provide  schedules  for  unit  arrival  at  ports,  and  issue 
port  calls  to  units.  It  will  include  the  ftmctionality  of  the  Mili¬ 
tary  Export  Traffic  System  II  (METS  II)  and  ASPUR. 

=  Integrated  Command,  Control,  and  Communications  System 

[Msq 

The  Military  Sealift  Command's  new  command,  control,  and 
communications  system  that  will  be  integrated  with  the 
Navy's  Operations  Support  System.  Both  are  xmder  develop¬ 
ment. 

=  Integrated  Vessel  Information  Planning  and  Analysis  System 
[MSC] 

The  system  will  provide  the  Military  Sealift  Command  with  a 
record  of  voyages  and  the  location  of  ships,  as  well  as  the  loca¬ 
tion  of  chartered  and  space-chartered  ships  operating  in  the 
Defense  Transportation  System.  Eventually,  IVIPS  will  be 
merged  into  the  ICS  system  module. 
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JOPES  =  Joint  Operations  Planning  and  Execution  System  [JCS] 

The  foundation  of  the  DoD's  conventional  command  and  con¬ 
trol  system,  which  is  comprised  of  policies,  procedures,  and 
reporting  systems  supported  by  automation.  It  is  used  to 
monitor,  plan,  and  execute  mobilization,  deployment,  employ¬ 
ment,  and  sustainment  activities  in  peace,  exercises,  crises,  and 
war. 

LIE  =  Logistics  Intelligence  File  [USA] 

Records  Army  MILSTRIP  transactions  placed  at  the  wholesale 
resupply  level  and  MILSTAMP  transactions  for  transportation 
from  origin  to  CONUS  destination,  or  from  port  of  embarka¬ 
tion  to  port  of  debarkation. 

LOGAIS  =  Logistics  Automated  Information  System  [USMC] 

Consists  of  a  family  of  Marine  Corps  planning,  deployment, 
and  redeployment  systems  that  help  to  bridge  the  gap  be¬ 
tween  JOPES  and  other  systems. 

MAGTF  II  =  Marine  Air  Ground  Task  Force  War  Planning  System  II 
[USMC] 

A  microcomputer-based  planning  system  that  supports  a  wide 
variety  of  high-intensity  operation^  requirements.  It  acceler¬ 
ates  the  development,  soiurcing,  analysis,  and  refinement  of 
plans  resulting  in  executable  JOPES  Time-Phased  Force  De¬ 
ployment  Data  Bases. 

MAIRS  =  Military  Air  Integrated  Reporting  System  [AMC] 

Records  and  displays  airlift  schedules,  aircraft  arrivals  and  de¬ 
partures,  and  aircraft  status.  It  is  compatible  with  the  second 
generation  of  CAPS  II. 

MDSS II  =  Marine  Air  Groimd  Task  Force  Deployment  Support  System  II 
[USMC] 

Aids  in  planning  for  and  supporting  rapid  military  deploy¬ 
ments  anywhere  in  the  world.  It  builds  and  maintains  a  data 
base  of  force  and  equipment  data  for  various  MAGTF  configu¬ 
rations. 
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METSII 


Military  Export  Traffic  System  II  [MTMC] 


MIDAS 


NATDS 


NAVADS 


OSS 


PACS 


PRAMS 


Provides  schedules  for  units  arriving  at  ports  and  issues  port 
calls  to  the  units.  It  supports  the  booking  of  all  surface  cargo 
and  is  the  current  traffic  management  system  at  Military  Traf¬ 
fic  Management  Command  area  commands.  It  will  be  replaced 
by  IBS. 

=  Military  and  International  Dispatch  and  Accoimtability  Sys¬ 
tem  [USPS] 

An  automated  dispatch  and  accountability  system  that  the 
United  States  Postal  Service  uses  to  monitor  the  movement  of 
all  international  and  military  mail. 

=  Navy  Automated  Transportation  Data  System  [USN] 

Records  TCMDs  for  lift  of  Navy  cargo  at  the  cargo  clearance 
authority  and  registers  them  with  either  the  Military  Air 
Clearance  Authority  or  TERMS. 

=  Navy  Automated  Transportation  and  Documentation  System 
[USN] 

Located  at  Navy  supply  centers  (now  tmder  DLA  manage¬ 
ment),  the  system  plans  and  document  shipments.  It  will  be 
replaced  by  DSS. 

=  Operations  Support  System  [USN] 

Provides  the  Chief  of  Naval  Operations  and  Fleet 
Commanders-in-Chief  with  a  single,  integrated  command  and 
control  system  to  receive,  process,  display,  maintain  and/or 
access  unit  characteristics,  employment  scheduling,  combat 
readiness,  warfighting  capabilities,  and  positional  information 
of  U.S.  and  allied  forces. 

=  Passenger  Automated  Check-in  System  [AMC] 

Records  passenger  check-ins  at  aerial  ports  of  embarkation 
and  correlates  the  information  with  PRAMS. 

=  Passenger  Reservation  and  Manifesting  System  [AMC] 

Records  non-unit  passenger  reservations,  issues  boarding 
passes,  and  generates  the  aircraft  manifest  for  fixed  aerial 
ports  of  embarkation. 
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ROAMS 


Replacement  Operations  Automation  Management  System 
[USA] 


SBSS 


SC&D 


SDS 


SEASTRAT 


Integrates  three  automated  Army  systems  (Automation  of  the 
Theater  Shelf  Requisitioning  Process,  FLOWCAP,  and  Auto¬ 
mation  of  the  Casualty  Analysis  Process)  to  identify  and  man¬ 
age  individual  non-unit  personnel  flows  into  a  theater. 

=  Standard  Base  Supply  System  [USAF]  ^ 

The  Air  Force's  base-level  inventory  management  system.  It 
aids  in  the  management  of  subsidiary  inventories  in  self- 
service  stores,  shop  stores,  or  intermediate-level  maintenance 
stock  points;  general  housekeeping  and  administrative  sup¬ 
plies  for  base  and  tenant  units;  and  maintenance  materiel  and 
repair  parts  for  the  direct  support  of  base  units. 

=  Stock  Control  and  Distribution  [USAF] 

Controls  storage,  allocation,  and  movement  of  Air  Force  Lo¬ 
gistics  Center  inventories  by  processing  requisitions  and  re¬ 
porting  on  status.  It  provides  asset  visibility,  timely  items 
status  to  customers,  and  on-time  issue  and  shipment  actions. 
It  will  be  replaced  by  DSS. 

=  Standard  Depot  System  [USA] 

Receives  data  from  depot  supply  and  maintenance  packaging 
preservation  centers,  warehouse  workers,  managers,  inventory 
clerks,  shippers,  planners,  transportation  personnel,  item  man¬ 
agers,  and  finance  officers  on  all  materiel  stored,  maintained, 
processed,  shipped,  or  handled  at  an  Army  depot.  It  supports 
day-to-day  depot  operations  and  management.  It  wiU  be  re¬ 
placed  by  DSS. 

Strategic  Planning  and  Analysis  System  [MSC] 

Provides  the  Military  Sealift  Command  with  the  capability  to 
rapidly  develop  movement  tables  from  time-phased  deploy¬ 
ment  data  inserted  during  the  deliberate  planning  process.  It 
also  assists  in  the  development  of  execution  movement  sched¬ 
ules  and  transportation  feasibility  analyses. 


A-9 


STACCS 


Standard  Theater  Army  Command  and  Control  System  [USA] 


Provides  automated  decision  support  tools  and  a  data  collec¬ 
tion  capability  to  facilitate  command  and  control  of  theater 
forces.  It  supports  commanders  and  staffs  at  Echelons  Above 
Corps  and  tracks  Army  unit  movements  within  theater.  The 
system  is  classified. 

STRADS  =  Strategic  Deployment  System  [MTMC] 

Enables  the  Military  Traffic  Management  Command  to  rapidly 
•  retrieve,  process,  analyze,  and  monitor  data  associated  with 
unit  deployments  and  mobilizations.  Using  JOPES  data,  it  as¬ 
sists  users  in  determining  the  feasibility  of  deployment  plans, 
provides  force  closure  and  surface  modes,  and  evaluates  in¬ 
stallation  outloading  and  port  throughput  capabilities.  When 
fully  operational,  it  will  be  the  Command's  secure  command 
cmd  control  system,  providing  movement  and  ocean  terminal 
information  to  permit  worldwide  monitoring. 

TC  ACCIS  =  Transportation  Coordinator's  Automated  Command  and  Con¬ 
trol  Information  System  [USA] 

The  Army  TC  AIMS  that  is  used  to  plan  and  execute  unit  de¬ 
ployments  and  redeployments  worldwide,  communicate  data 
to  the  Forces  Command  for  updating  the  JOPES,  and  commu¬ 
nicate  data  to  the  Military  Traffic  Management  Command  for 
port  operations  and  load  planning.  It  generates  air  load  plans, 
air  cargo  manifests,  unit  movement  data,  convoy  march  tables 
and  clearance  requests,  rail  load  plans,  bills  of  lading,  and  bar¬ 
code  labels. 

TC  AIMS  =  Transportation  Coordinator's  Automated  Information  for 
Movement  System  [USA/USMC/USAF] 

A  family  of  systems  that  automates  the  planning,  organizing, 
coordinating,  and  controlling  of  unit-related  deployment  ac¬ 
tivities  supporting  the  overall  deployment  process.  It  permits 
transportation  offices  to  maintain  an  automated  data  base  of 
current  unit  movement  data.  TC  AIMS  is  a  generic  term  for 
TC  ACCIS,  LOGAIS/TC  AIMS,  and  CMOS. 
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TERMS 


TMIS 


TMS 


TOPS 


TRAC2ES 


Terminal  Management  on-line  System  [MTMC] 

Records  cargo  data  for  surface  movements  at  the  Military 
Traffic  Management  Command  area  commands.  It  also  facili¬ 
tates  cargo  receipt,  staging,  and  planning  at  ports  and  gener¬ 
ates  the  ship  manifest  upon  completion  of  loading.  This 
system  will  be  replaced  by  the  WPS. 

Theater  Medical  Information  System  [OSD(HA)] 

Provides  automated  support  to  clinical  care,  ancillary  services, 
patient  administration,  medical  regulating,  medical  logistics, 
cmd  blood  distribution  fimctions.  It  also  provides  manage¬ 
ment  information  to  medical  decision  makers  from  unit  to  in¬ 
termediate  headquarters  levels.  It  will  interface  with  JOPES, 
DMRIS,  and  GTN. 

Transportation  Management  System  [USMC] 

Provides  the  capability  to  monitor  the  movement  of  cargo,  and 
to  track,  audit,  certify,  and  provide  payment  for  all  billings  re¬ 
ceived  for  the  movement  of  Marine  Corps  freight,  personnel, 
and  contracted  accessorial  services. 

Transportation  Operational  Personal  Property  Standard  Sys¬ 
tem  [MTMC] 

Automates  the  processes  and  procedures  governing  the  move¬ 
ment  and  storage  of  personal  property  belonging  to  military 
members  and  DoD  civilians.  It  provides  the  processing  and 
communications  necessary  for  source  data  automation  and  en¬ 
sures  the  accurate  and  timely  exchange  of  information  be¬ 
tween  personal  property  offices  and  finance  centers. 

TRANSCOM  Command  and  Control  Evacuation  System 
[USTRANSCOM] 

The  medical  component  of  GTN  that  functions  as  a  command 
and  control  system  to  provide  for  global  patient  movement 
and  regulating.  It  also  provides  patient  intransit  visibility, 
monitors  critical  patient  medical  equipment  pools,  and  assists 
in  roimd-trip  transportation  of  patient  attendants. 
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TRAIS 


TRAMS 


TSM 


WHIST  MOD 


WPS 


Transportation  Reporting  and  Inquiry  System  [AMC] 

An  AMC  System  that  processes  transportation  data  received 
from  CAPS  II  cargo  ports  worldwide.  It  provides  transporta¬ 
tion  management  information  to  plan  resource  allocations  and 
analyze  system  performance. 

Transportation  Automated  Management  System  [DLA] 

Processes  shipment  data  and  operates  on  a  two-tier  system  ar¬ 
chitecture  design.  Its  ftmctions  include  entering  and  validat¬ 
ing  shipment  requests,  awarding  shipments  to  carriers  with 
reason  codes  for  not  selecting  the  low-cost  carrier,  recording 
service  failures,  creating  Government  bills  of  lading  (GBLs) 
and  correction  notices,  printing  shipping  documents,  transmit¬ 
ting  GBL  data  to  host  computers,  creating  transportation  dis¬ 
crepancy  reports,  producing  management  reports,  and 
applying  local  non-use  carrier  penalties. 

Terminal  Support  Module  [MTMC] 

Functions  as  a  minicomputer-based  terminal  management  and 
cargo  documentation  system.  It  uses  LOGMARS  technology 
for  automated  data  capture.  It  will  be  replaced  by  WPS. 

Worldwide  Household  Goods  Information  System  for  Traffic 
Management  Modernization  [MTMC] 

A  decision-support  system  that  provides  historical  movement, 
quality  assurance,  and  rate  acquisition  information  to  the  Mili¬ 
tary  Traffic  Management  Command.  It  supports  policy,  pro¬ 
gram,  and  management  decisions. 

Worldwide  Port  System  [MTMC] 

A  new  system  being  fielded  that  will  function  as  the  port  oper¬ 
ating  system  for  military  ocean  terminals.  Navy  port  activities. 
Army  Transportation  Terminal  Units  and  Automated  Cargo 
Documentation  Detachments.  It  will  replace  TERMS  and 
DASPS-E. 
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Appendix  B 


Glossary  of  Terms 


This  appendix  defines  some  of  the  terms  used  in  this  plan. 

Accompanying  supplies:  Materiel  accompanying  and  considered  part  of  a  de¬ 
ploying  military  unit.  Accompanying  supplies  are  documented  with  a 
MILSTAMP  unit  movement  transportation  control  number. 

Automatic  identification  technology  (AIT):  Consists  of  process  control  hard¬ 
ware,  application  software,  and  hybrids  that  provide  industry-standard  real-time 
data  acquisition  to  enhance  productivity.  It  includes  bar  codes,  radio  frequency 
identification,  magnetic  stripes,  smart  cards,  and  optical  laser  cards.  In  DoD  lo¬ 
gistics,  these  technologies  facilitate  the  capture  of  supply,  maintenance,  and 
transportation  information  for  inventory  and  movement  management,  shipment 
diversion  and  reconstitution,  and  personnel  or  patient  identification. 

Cargo:  Any  items  or  supplies  in  transit. 

Deployment:  The  relocation  of  forces  to  areas  of  operation. 

Destination:  The  location  to  which  units,  materiel,  or  individuals  are  traveling. 
It  is  designated  by  the  CINCs,  Military  Services,  or  Defense  agencies. 

Electronic  data  interchange  (EDI):  The  computer  to  computer  exchange  of  data 
from  common  business  documents  using  standard  data  formats. 

Intransit  visibility  (ITV):  The  ability  to  track  the  identity,  status,  and  location  of 
DoD  unit  and  non-unit  cargo  (excluding  bulk  petroleum,  oils,  and  lubricants); 
passengers;  medical  patients;  and  personal  property  from  origin  to  the  consignee 
or  destination  designated  by  the  CINCs,  Military  Services,  or  Defense  agencies, 
during  peace  contingencies  and  war. 

Joint  Transportation  Corporate  Ittformation  Management  (CIM)  Center 
(JTCC):  An  organization  chartered  by  the  Deputy  Under  Secretary  of  Defense 
(Logistics)  on  11  August  1993.  It  was  established  under  CINCTRANS  and  desig¬ 
nated  as  the  functional  manager  for  implementing  the  CIM  initiative  for  Defense 
transportation.  Its  mission  is  to  improve  the  efficiency  and  effectiveness  of  the 
DTS  through  the  application  of  functional  process  improvement  techniques  and 
central  control  of  transportation  related  C-4  system  development. 

Legacy  systems:  A  term  used  to  describe  automated  information  systems  that 
perform  the  same  functions  as  those  performed  by  selected  migration  systems. 
Legacy  systems  have  a  finite  life,  with  aU  further  system  development  and  mod¬ 
ernization  resources  applied  to  the  selected  migration  system. 
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Manifest:  A  document  listing  in  detail  the  passengers  or  cargo  carried  aboard  a 
ship  or  airplane. 

Migration  systems:  Existing  or  planned  and  approved  automated  information 
systems  officially  designated  to  support  standard  processes. 

Military  Standard  Requisition  and  Issue  Procedures  (MILSTRIP):  Uniform 
procedures,  codes,  formats,  forms,  and  time  standards  that  control  the  inter¬ 
change  of  logistics  information  relating  to  requisitioning,  supply  advice,  supply 
status,  materiel  issues  and  receipts,  and  materiel  return  processes. 

Military  Standard  Transportation  and  Movement  Procedures  (MILSTAMP). 
Standard  data  elements,  codes,  formats,  documents,  forms,  rules,  methods,  and 
procedures  that  DoD  Components  and  other  U.S.  Government  Agencies/ civil 
authorities  use  in  the  transportation  and  movement  of  materiel  to,  within,  and 
beyond  the  Defense  Transportation  System  (DTS). 

Movement  control:  The  planning,  routing,  scheduling,  and  control  of  personnel 
and  freight  movements  over  lines  of  communication.  It  includes  the  reception 
and  onward  movement  of  personnel,  equipment,  and  supplies. 

Multitechnology  automated  reader  card  (MARC):  A  form  of  identification  card 
containing  personal  medical  data  used  to  process  patients  into  medical  treatment 
facilities. 

Non-unit  cargo:  Supplies  in  transit  that  are  not  part  of  a  unit  or  its  equipment. 
It  does  not  include  unit  accompanying  supplies.  Synonymous  with  sustainment 
cargo. 

Non-unit  personnel:  All  personnel  requiring  transportation  to  or  from  an  area 
of  operations  other  than  those  assigned  to  a  specific  unit.  Examples  of  non-unit 
personnel  are  filler,  replacement,  temporary  duty,  temporary  additional  duty,  ci¬ 
vilian  personnel,  and  medical  evacuees. 

Origin:  The  location  from  which  personnel  or  materiel  commence  movement  to 
a  destination. 

Passenger:  Any  individual  who  is  being  transported  and  is  not  a  member  of  the 
assigned  transport  vehicle  operating  crew. 

Patient:  A  sick,  injured,  wotmded,  or  other  person  requiring  medical/  dental 
care  or  treatment. 

Patient  attendant:  Any  person  designated  to  provide  care  to  a  patient  who  is  in 
transit.  A  patient  attendant  is  usually  a  military  and/ or  medical  person,  but  may 
be  an  accompanying  family  member. 
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Port  of  debarkation  (POD):  A  station  that  serves  as  an  authorized  port  to  proc¬ 
ess  and  clear  aircraft,  ships,  and  traffic  for  entrance  to  the  country  in  which  lo¬ 
cated. 

Port  of  embarkation  (POE):  A  station  that  serves  as  an  authorized  port  to  proc¬ 
ess  and  clear  aircraft ,  ships,  and  traffic  for  departure  from  a  particular  coxmtry. 

Redeployment:  The  process  of  evacuating,  moving,  or  returning  units,  non-unit 
cargo,  and  non-unit  personnel  from  a  theater  of  operations  to  another  theater  of 
operations. 

Retrograde:  Non-unit  cargo  and  personnel  evacuated  from  a  theater  of  opera¬ 
tions  to  the  CONUS. 

Shipment  identification  number:  The  unique  number  that  identifies  a  ship¬ 
ment.  (Includes  GBL,  TCMD,  lead  TCN,  air  manifest,  etc.) 

Standard  Automated  Input  Media  Device  (SAIMD):  A  credit-card  sized  stor¬ 
age  media  that  contains  essential  ITV  information  and  additional  space  for  sup¬ 
plemental  data.  This  card  may  be  used  to  carry  persormel,  medical  and  logistics 
data;  e.g.,  MARC,  Soldier  Readiness  Card  (SRC),  etc.;  and  is  machine  readable 
using  automated  reading  devices. 

Supercargo:  Personnel  that  accompany  cargo  onboard  a  ship  for  the  purpose  of 
performing  enroute  maintenance  and  security. 

Sustainment:  The  process  of  maintaining  the  level  and  duration  of  operational 
activity  required  to  achieve  established  military  objectives.  It  includes  providing 
and  maintaining  the  levels  of  forces,  materiel,  and  consumables  necessary  to  sup¬ 
port  the  military  effort. 

Sustainment  cargo:  Supplies  in  transit  that  are  not  part  of  a  unit  or  its  equip¬ 
ment  and  therefore  not  documented  with  a  MILSTAMP  unit  movement  trans¬ 
portation  control  number.  Synonymous  with  non-unit  cargo. 

Theater:  A  geographical  area  outside  the  CONUS  for  which  a  commander  of  a 
unified  command  has  been  assigned  military  responsibility. 

Total  asset  visibility  (TAV):  The  capability  that  permits  operational  and  logis¬ 
tics  managers  to  determine  and  act  on  timely  and  accurate  information  about  the 
location,  quantity,  condition,  movement,  and  status  of  Defense  materiel.  It  in¬ 
cludes  assets  that  are  instorage,  inprocess,  and  mtransit. 

Trading  partner:  A  term  used  frequently  in  EDI  to  indicate  a  business  relation¬ 
ship  with  another  company  or  activity. 

Transportation  control  number  (TCN):  A  unique  17-position  alphanumeric 
data  element  assigned  to  control  a  shipment  unit  throughout  the  transportation 
pipeline. 
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Transportation  Movement  and  Control  Document  (TCMD):  The  ME.STAMP 
shipment  information  document  (DD  Form  1384).  It  provides  advance  notice  of 
shipments  and  the  information  necessary  to  process  the  shipments  through  the 
Defense  Transportation  System.  The  TCMD  is  the  basis  for  preparation  of  air 
and  surface  manifests  and  for  compiling  logistics  reports. 

Unit:  Any  military  element  whose  structure  is  prescribed  by  an  authority,  such 
as  a  Table  of  Organization  and  Equipment. 

Unit  equipment:  The  equipment  prescribed  to  be  in  a  unit's  possession  by  an 
authority  such  as  a  Table  of  Organization  and  Equipment.  The  transportation  of 
rmit  equipment  is  documented  with  a  MILSTAMP  unit  movement  transportation 
control  number. 

Unit  line  number  (ULN):  Two  alphanumeric  characters  (the  fragmentation  and 
insert  codes)  added  to  a  force  requirement  number  to  identify  military  units  for  a 
particular  operational  plan  (OPLAN). 

Unit  personnel:  All  personnel  assigned  or  attached  to  a  specific  unit  and  requir¬ 
ing  movement  as  a  unit  to  or  from  a  theater  or  area  of  operations. 

Value-added  network  (VAN):  A  computer  accessible  by  a  data  communications 
network  that  provides  a  variety  of  value-added  services  designed  to  simplify 
communication  among  EDI  trading  partners.  Some  of  those  services  include 
mailboxing  that  allows  trading  partners  to  independently  schedrxle  their  data  ex¬ 
change;  commxinications  protocol  and  speed  (data  rate)  conversioirs  that  permits 
communication  among  incompatible  computers;  and  recordkeeping  that  pro¬ 
vides  audit  trails. 
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Appendix  C 

Implementation  Plans 


Introduction 

This  appendix  proposes  a  methodology  and  various  schedules  for  imple¬ 
menting  the  functional  operating  concepts  discussed  in  Chapter  3.  The  sched¬ 
ules  show  estimated  times  required  to  complete  the  implementation  tasks, 
although  the  tasks  and  their  completion  times  will  change  as  work  progresses. 
Table  C-1  divides  the  implementation  tasks  into  four  categories  of  plans:  sys¬ 
tems  development;  Global  Transportation  Network  (GTN)  system  interfaces; 
other  system  interfaces;  and  enhancing  source  data.  It  also  identifies  the  page 
within  this  appendix  where  each  category  or  subcategory  is  addressed. 

Table  C-1. 

Implementation  Plan  by  Category 


Category 

Page 

Introduction 

C-1 

Systems  development 

C-2 

Joint  theater  transportation  system 

C-2 

TRAC2ES  development 

C-6 

GTN  system  interfaces 

C-10 

Other  system  interfaces 

C-1 2 

Enhancing  source  data 

C-14 

Implement  EDI  capability  at  Defense  ordnance  shipping  activities 

C-14 

Capture  ordnance  data  from  non-EDI  shipping  activities;  expand  DTTS 
to  other  modes 

C-14 

Vendor 

C-1 8 

Government  bill  of  lading  (GBL) 

C-23 

Commercial  bill  of  lading  (CBL)/small  parcel 

C-27 

Carrier  status 

C-31 

Standard  automated  input  media  device  (SAIMD) 

C-36 

MILSTAMP 

C-39 

Personal  property 

C-44 

Note:  TRAC2ES  =  TRANSCOM’s  Regulating  and  Command  and  Control  Evacuation  System;  EDI  =  elec¬ 
tronic  data  interchange;  DTTS  =  Defense  Transportation  Tracking  System. 


Systems  Development 


The  Department  of  Defense  (DoD)  needs  to  develop  two  additional  systems 
in  order  to  achieve  a  comprehensive  intransit  visibility  (ITV)  system:  a  theater 
transportation  system  and  TRAC2ES.  The  implementation  plans  for  these  sys¬ 
tems  follow. 


Joint  Theater  Transportation  System 

The  Joint  Transportation  Corporate  Information  Management  Center  0TCC) 
will  support  the  development  and  implementation  of  a  joint  theater  transporta¬ 
tion  system.  Such  a  system  will  operate  from  port  of  debarkation  (POD)  forward 
to  destination,  eind  from  theater  origin  to  port  of  embarkation  (POE).  Table  C-2 
lists  the  tasks  associated  with  this  effort.  The  tasks  are  described  in  more  detail 
below. 

Table  C-2. 

Joint  Theater  Transportation  System  Implementation  Plan 

1.0  Develop  functional  requirements 

1.1  Designate  PEA 

1.2  Establish  baseline 

1 .3  Establish  performance  objectives 

1 .4  Develop  operating  concept 

1 .5  Develop  detailed  data  requirements 
2.0  Develop  technical  operating  requirements 

2.1  Identify  technical  requirements 

2.2  Establish  program  requirements 

2.3  Designate  acquisition  agency 

2.4  Secure  funding 

2.5  Develop  system  integration  strategy 
3.0  Develop,  integrate,  and  test  system 

3.1  Develop  the  system 

3.2  Arrange  for  telecommunications 

3.3  Train  operators 

3.4  Test  the  system 

3.5  Field  the  system 

4.0  Implement  production  system 


1.0  Develop  Functional  Requirements 


In  coordination  with  the  Joint  Staff,  DUSD(L)  will  designate  a  project  execu¬ 
tive  agent  (PEA)  for  developing  the  theater  transportation  system,  JTCC  will  es¬ 
tablish  a  baseline  of  current  capabilities,  establish  performance  objectives, 
develop  a  "to  be"  operating  concept,  and  finalize  theater  data  requirements. 


1.1  Designate  PEA 


The  DUSD(L),  in  coordination  with  the  Joint  Staff,  will  designate  a  PEA  for 
managing  the  development  of  the  theater  system.  JTCC  will  support  the  PEA. 


1.2  Establish  Baseline 

The  JTCC  will  establish  a  technical  and  fxmctional  baseline  of  current  theater 
systems.  Models  depicting  the  systems  as  they  currently  operate  will  be  devel¬ 
oped  to  identify  specific  areas  for  improvement  and  determine  the  current  activ¬ 
ity  costs. 


1.3  Establish  Performance  Objectives 

Under  the  guidance  of  the  project  executive  agent,  JTCC  will  support  per¬ 
formance  objectives  for  the  future  theater  transportation  system.  At  a  mmimum, 
the  objectives  will  meet  the  requirements  of  the  models  produced  during  the 
Army/ Marine  Corps  Battlefield  Logistics  effort  and  the  Theater  Combatant  Lo¬ 
gistics  effort  sponsored  by  the  Deputy  Under  Secretary  of  Defeiise,  Logistics 
[DUSD(L)]  and  the  Joint  Staff  (J4),  respectively.  The  JTCC  wiU  coordinate  objec¬ 
tives  with  all  CINCs,  Military  Services,  DUSD(L),  and  the  Joint  Staff. 


1.4  Develop  Operating  Concept 

With  the  participation  of  the  CINCs,  Military  Services,  DUSD(L),  and  Joint 
Staff,  the  JTCC  will  develop  the  to  be  model  of  the  theater  transportation  operat¬ 
ing  concept.  This  model  will  serve  as  the  basis  for  developing  the  theater  trans¬ 
portation  system. 


1.5  Develop  Detailed  Data  Requirements 

Based  upon  the  to  be  process  model  and  the  Transportation  Logical  Data 
Model  (currently  being  developed),  the  JTCC  will  develop  a  detailed  data  model 
for  the  theater  transportation  system.  The  data  model  will  comply  with  existing 
DoD  data  standards. 
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2.0  Develop  Techmcal  Operating  Requirements 


In  coordination  with  the  CINCs  and  DUSD(L),  the  JTCC  will  develop  techni¬ 
cal  operating  requirements  for  the  future  theater  transportation  system.  Techni¬ 
cal  requirements  include  those  specifications  that  provide  compliance  with  the 
DoD  Technical  Architecture  Framework  for  Information  Management  (TAFIM) 
as  well  as  operational  considerations  such  as  deployability,  sustainability,  proc¬ 
essing  and  storage  capacities  and  transmission  rates.  In  addition,  funding  will 
be  secured,  an  acquisition  agency  identified,  and  an  integration  strategy 
developed. 


2.1  Identify  Technical  Requirements 

Using  the  established  models  and  analyzing  expected  scenarios,  the  JTCC 
will  work  with  each  CINC  to  determine  expected  wartime  technical  require¬ 
ments.  These  requirements  will  consider  environmental  and  operational  consid¬ 
erations  as  well  as  established  DoD  standards. 


2.2  Establish  Program  Requirements 

Comparing  the  current  technical  baseline  to  the  projected  technical  require¬ 
ments  and  analyzing  the  established  operational  requirements,  the  JTCC  will  de¬ 
velop  a  program  for  the  acquisition  of  a  standard  theater  transportation 
program.  The  JTCC  will  recommend  to  DUSD(L),  through  the  Joint  Staff,  an  ac¬ 
quisition  program  that  includes  multi-year  ftmding,  an  acquisition  strategy,  and 
that  an  acquisition  agency  be  identified. 


2.3  Designate  Acquisition  Agency 

The  PEA  will  recommend,  through  the  Joint  Staff,  that  the  DUSD(L)  desig¬ 
nate  either  USTRANSCOM  or  a  Military  Service  as  the  acquisition  agency  to  de¬ 
velop  and  integrate  the  theater  transportation  system. 


2.4  Secure  Funding 


The  JTCC  and  the  acquisition  agent  will  continue  to  support  DUSD(L)  ef¬ 
forts  to  obtain  sufficient  funding  to  support  the  acquisition.  Where  appropriate, 
the  JTCC  will  conduct  analyses  and  recommend  funding  offsets  from  existing 
programs. 


2.5  Develop  System  Integration  Strategy 

The  JTCC  will  work  with  the  acquisition  agency  and  each  CINC  to  assist  in 
developing  a  systems  integration  and  fielding  strategy.  The  CINCs  will  ensure 
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that  sufficient  support  capability  (such  as  telecommunications  capability)  will  be 
available  for  implementation.  The  JTCC  will  work  with  other  Corporate  Infor¬ 
mation  Management  activities  to  ensure  that  the  emerging  theater  transportation 
system  is  fuUy  interoperable  with  systems  being  fielded  to  support  other  func¬ 
tional  areas. 


3.0  Develop,  Integrate  AND  Test  Systhem 

In  this  task,  the  acquisition  agent  and  JTCC  will  develop,  integrate,  test,  and 
field  the  theater  transportation  system.  In  addition,  the  acquisition  agency  will 
ensure  the  availability  of  telecommunications  and  establish  a  training  program. 


3.1  Develop  the  System 

The  acquisition  agency  will  prepare  and  gain  acquisition  approval  for  the 
systems  development  and  develop  the  system.  The  development  effort  will  rely 
on  integrating  existing  system  modules  as  well  as  developing  new  capabilities. 
The  acquisition  strategy  will  be  based  upon  the  recommendations  of  Subtask  2.2, 
but  wiU  always  include  program  direction  by  the  JTCC  and  functional  oversight 
by  the  PEA. 


3.2  Arrange  for  Telecommunications 

The  acquisition  agency,  with  JTCC  oversight  and  coordination  with  the  Mili¬ 
tary  Services,  Defense  agencies  and  Unified  Commands,  will  develop  and  ad¬ 
minister  a  telecommunication  support  plan  for  each  CESTC  and  the  CONUS 
support  base.  The  plan  will  address  intratheater  and  intertheater  commmuca- 
tions  capabilities,  requirements  and  efforts  to  provide  assured  communication 
during  contingencies. 


3.3  Train  Operators 


The  acquisition  agency  will  develop  training  programs  to  support  the  field¬ 
ing  of  the  system.  Training  programs  will  include  institutional  training  within 
the  sustaining  base  and  field  training  within  the  units  receiving  the  system. 


3.4  Test  the  System 


The  JTCC  will  ensure  that  the  PEA  judges  the  functional  acceptability  of  the 
theater  transportation  system  by  including  participation  from  all  CINCs,  Mili¬ 
tary  Services,  Defense  agencies  and  Joint  Staff.  Technical  acceptability  will  be 
provided  by  a  joint  JTCC  and  DISA  evaluation.  Interim  evaluation  of  functional¬ 
ity  and  technical  sufficiency  will  be  provided  throughout  the  development  and 
fielding  of  the  system. 
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3.5  Field  the  System 


The  acquisition  agency  will  field  the  tested  system  at  all  deployed  theater 
locations. 


4.0  Implement PRODUcnoN  System 

Upon  completion  of  system  testing  and  modification,  DoD  should  begin  to 
employ  the  system  in  a  fully  operational  environment. 


Implementation  Schedule 

Figure  C-1  shows  the  schedule  for  developing  and  implementing  the  joint 
theater  transportation  system. 


Major  activity 

Lead  agent 

Schedule 

1995 

1996 

1997 

Jan 

Jul 

Jan 

Jul 

Jan 

_ 1 

Jul 

1.0  Develop  functional 
requirements 

JTCC 

— 

■ 

■ 

■ 

mm 

2.0  Develop  technical 
operating  requirements 

JTCC 

■ 

■ 

■ 

■ 

3.0  Develop,  integrate, 
and  test  system 

Acquisition  agency 

■ 

■ 

■ 

4.0  Implement  production 
system 

USTRANSCOM 

■ 

■ 

■ 

■ 

■ 

E 

Project  team  leader —  USTRANSCOM. 

Note;  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-1. 

Joint  Theater  Transportation  System  Implementation  Schedule 


TRAC2ES  Development 

This  section  identifies  the  tasks,  responsible  organizations,  and  schedule  for 
developing  and  implementing  TRAC2ES.  Table  C-3  lists  the  tasks  associated 
with  this  effort.  We  describe  each  task  in  more  detail  below. 

1.0  Finalize  Functional  Requirements 

A  project  team,  led  by  USTRANSCOM,  with  assistance  from  Military  Serv¬ 
ice,  Joint  Staff,  CINCs,  and  Office  of  the  Assistant  Secretary  of  Defense  (Health 
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Table  C-3. 

TRACIES  Development  and  Implementation  Plan 

1 .0  Finalize  functional  requirements 

1.1  Finalize  operating  concept 

1 .2  Finalize  data  requirements 

1 .3  Resolve  business,  legal,  and  security  issues 
2.0  Finalize  technical  operating  requirements 

2.1  Identify  application  systems  modifications 

2.2  Establish  telecommunications  strategy 

2.3  Review  and  complete  hardware  requirements 
3.0  Integrate  and  test  TRAC2ES 

3.1  Procure,  install  software/hardware 

3.2  Modify  application  system 

3.3  Develop  program  interfaces 

3.4  Arrange  for  telecommunications 

3.5  Update  operational  procedures 

3.6  Train  operators 

3.7  Test,  modify,  and  evaluate  systems 
4.0  Implement  system 


Affairs)  representatives,  will  finalize  the  operating  concept  and  data  require¬ 
ments;  identify  the  application  system  modifications;  and  identify  associated 
business,  legal,  and  security  issues  for  implementing  TRAC2ES. 

1.1  Finalize  Operating  Concept 

In  this  subtask,  the  project  team  reviews  the  operating  concept  and  makes 
adjustments  to  that  concept,  as  required.  Those  adjustments  include  the  use  of 
multitechnology  automated  reader  card  (MARC)  technology  for  patient  source 
data  and  interfaces  with  other  medical  information  systems. 

1.2  Finalize  Data  Requirements 

In  this  subtask,  the  project  team  reviews  the  results  of  the  TRAC2ES  proto¬ 
type  testing  to  determine  if  any  additional  data  requirements  need  to  be 
satisfied. 


1.3  Resolve  Business,  Legal,  and  Security  Issues 

In  this  subtask,  the  project  team  resolves  all  business,  legal,  and  security  is¬ 
sues  associated  with  implementing  the  proposed  operating  concept. 
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2.0  Finalize  Technical  Operahng  Requirements 


The  project  team  will  identify  all  application  system  modifications,  and  re¬ 
views  and  completes  the  hardware  requirements  and  telecommunications 
strategy. 


2.1  Identify  Application  Systems  Modifications 

The  project  team  will  determine  if  any  application  system  modifications  are 
required. 


2.2  Establish  Telecommunications  Strategy 

The  project  team  will  establish  the  telecommunications  links  to  accommo¬ 
date  the  proposed  operating  concept. 


2.3  Review  and  Complete  Hardware  Requirements 

The  project  team,  in  conjunction  with  user  representatives,  will  review  and 
complete  the  hardware  requirement  for  TRAC2ES. 

3.0  Integrate  AND  Test  TRAC2ES 

In  this  task,  the  Military  Services'  medical  treatment  facilities.  Theater  Pa¬ 
tient  Movement  Requirements  Centers,  Global  Patient  Movement  Requirements 
Center,  Joint  Medical  Regulating  Offices,  Armed  Services  Medical  Regulating  Of¬ 
fice,  and  Military  Service  and  CINC  Surgeon  General  staffs  will  acquire 
TRAC2ES,  and  then  test,  modify,  and  evaluate  the  system. 


3.1  Procure,  Install  Software/Hardware 

The  project  team  will  work  with  various  users  to  ensure  that  they  acquire 
the  needed  hardware  and  software. 


3.2  Modify  Application  System 

The  project  team  will  modify  the  application  system,  based  on  the  experi¬ 
ence  of  field  activities  testing  the  TRAC2ES  protot3rpe. 
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3.3  Develop  Program  Interfaces 


The  project  team  will  develop  the  appropriate  interfaces  between  the  Com¬ 
posite  Health  Care  System  (CHCS)  and  the  Command  and  Control  Information 
Process  System  (C2IPS);  Global  Decision  Support  System  (GDSS);  and  Theater 
Medical  Information  System  (TMIS). 


3.4  Arrange  for  Telecommunications 

The  project  team  will  ensure  that  the  telecommunications  lines  for  system 
interfaces  are  available  and  satisfy  information  exchanges  requirements. 


3.5  Update  Operational  Procedures 

The  project  team  will  establish  and  publish  standardized  procedures  for 
TRAC2ES  implementation.  The  procedures  will  address  sending  patient  move¬ 
ment  requests;  manifesting  patients,  attendants,  and  equipment;  and  reporting 
bed  status. 


3.6  Train  Operators 


The  project  team  will  oversee  development  of  a  plan  for  training  system 
operators. 


3.7  Test,  Modify,  and  Evaluate  Systems 

The  project  team  will  oversee  the  fielding  of  TRAC2ES,  establish  the  tele¬ 
communications  links,  test  the  system  at  selected  sites,  and  make  any  necessary 
system  modifications.  Testing  will  be  accomplished  in  two  phases.  The  first 
phase  should  consist  of  testing  the  system  internally  using  sample  data, 
evaluating  the  results,  and  then  making  appropriate  modifications.  In  the  sec¬ 
ond  phase,  system  testing  should  use  real  data  sent  by  a  selected  number  of  loca¬ 
tions.  During  each  phase,  all  system  components  —  telecommtmicatiojis, 
hardware/ software,  interface  programs,  and  application  systems  —  should  be 
evaluated  and  modified  as  appropriate.  Both  phases  should  be  repeated  xmtil 
the  system  passes  all  established  testing  criteria. 


4.0  Implement  System 

Upon  completion  of  testing,  evaluation,  and  modification,  the  system  transi¬ 
tions  to  a  production  environment. 
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4 


Implementation  Schedule 

Figure  C-2  shows  the  schedule  for  implementing  TRAC2ES  to  capture  all  pa¬ 
tient  movement  data. 


Major  activity 

Lead  agent 

Schedule 

1993 

1994 

1995 

1996 

1997 

1998 

1999 

1 .0  Finalize  functional 
requirements 

USTRANSCOM 

2.0  Finalize  technical 
operating  requirements 

USTRANSCOM 

■■■ 

■ 

■ 

3.0  Integrate  and  test 
TRAC2ES 

USTRANSCOM 

■ 

4.0  Implement  system 

USTRANSCOM 

Project  team  leader —  USTRANSCOM. 


Figure  C-2. 

TRACIES  Development  and  Implementation  Schedule 


GTN  System  Interfaces 

As  described  in  the  operating  concept  in  Qaapter  3,  the  ITV  module  of  GTN 
needs  to  interface  with  13  systems  before  the  DoD  can  achieve  the  required  ITV. 
Figure  C-3  identifies  those  systems  and  their  anticipated  GTN  interface  develop¬ 
ment  schedule.  The  sequence  of  the  interfaces  is  based  upon  the  priorities  as¬ 
signed  in  Chapter  4.  The  estimated  time  for  each  interface,  approximately 
one  year,  is  based  upon  experience  gained  with  the  GTN  Version  2  Prototype, 
where  the  contractor  worked  on  three  or  more  interfaces  concurrently. 

While  the  priorities  and  timelines  for  developing  GTN  system  interfaces  are 
based  on  reasonable  assumptions  and  performance  standards,  each  interface  is 
unique,  as  discussed  below. 

♦  TC  AIMS.  The  family  of  Transportation  Coordinator's  Automated  Informa¬ 
tion  for  Movement  Systems  (TC  AIMSs)  —  TC  ACCIS,  CMOS, 
LOGAIS/TC  AIMS  —  will  probably  require  separate  interfaces  with  GTN. 
The  GTN  development  effort  for  those  interfaces  could  be  simplified 
through  the  use  of  standard  data  elements,  formats,  and  technical  ap¬ 
proaches.  Therefore,  this  effort  should  require  fewer  resources  than  three 
unrelated  system  interfaces. 

♦  Future  theater  system.  The  GTN  interface  with  the  DoD's  new  joint  theater 
transportation  system  cannot  be  completed  until  that  system  is  developed. 
In  the  interim,  GTN  will  use  information  from  Standard  Theater  Army  Com¬ 
mand  and  Control  System  (ST ACCS)  and  Department  of  the  Army 
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Movements  Management  System  —  Redesigned  (DAMMS-R)  to  provide 
partial  theater  ITV. 

♦  STACCS.  A  GTN  interface  with  STACCS  could  provide  ITV  information  for 
Army  unit  movements  in  Europe  in  the  near  term.  It  will  ultimately  be  re¬ 
placed  by  the  theater  transportation  system. 


System 


1995 


g 

Schedule 


1996 


1997 


1998 


1999 


Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

TC  AIMS 

Theater  system 

STACCS 

mmm 

DAMMS-R 

CFM 

WPS  (enhance) 

CAPS  II  (enhance) 

DTTS 

Postal  system 

GDSS 

9 

ICS 

DAAS 

m 

PRAMS 

▲ 

"Month  in  schedule  column  indicates  a  six-month  period  beginning  with  that  month. 


Figure  C-3. 

GTN  Sytem  Interfaces  for  ITV 


♦  DAMMS-R.  Like  STACCS,  DAMMS-R  could  provide  CTN  with  partial 
theater  cargo  ITV  information  in  the  near  term.  It  also  will  be  replaced  by 
the  theater  transportation  system. 

♦  CFM.  The  CONUS  Freight  Memagement  (CFM)  system  will  provide  CTN 
with  a  myriad  of  CONUS  transactions  that  contribute  to  ITV  of  non-tmit 
cargo  shipments.  For  this  reason,  the  development  of  a  GTN  interface  will 
likely  require  more  than  one  year. 

♦  WPS.  An  interface  between  the  GTN  prototype  and  the  Worldwide  Port 
System  (WPS)  already  exists.  In  this  task,  the  capabilities  of  that  interface 


C-11 


will  be  expanded  to  include  vendor,  carrier  status,  and  enhanced 
MILSTAMP  data. 


♦  CAPS  II.  An  interface  between  the  Consolidated  Aerial  Port  System  II 
(CAPS  II)  and  the  GTN  prototype  already  exists.  In  this  task,  that  interface 
will  be  expanded  to  include  vendor  and  enhanced  MILSTAMP  data. 

♦  DTPS.  The  DoD  has  two  main  alternative  technical  approaches  for  the  inter¬ 
face  between  DTTS  and  GTN.  The  first  would  replicate  the  DTTS  data  base 
in  GTN,  and  the  second  would  use  an  on-line  inquiry  capability  from  GTN 
to  DTTS  for  individual  ordnance  shipment  tracking  information.  The  tech¬ 
nical  approach  that  is  chosen  may  change  the  proposed  time  line. 

♦  Postal  System.  The  interface  between  GTN  and  the  U.S.  Postal  Service  will 
not  become  a  reality  until  the  DoD  develops  procedures  and  tracking  re¬ 
quirements  for  mail  shipments,  and  the  postal  service  develops  a  system  ca¬ 
pable  of  satisfying  those  procedures  and  requirements. 

♦  GDSS.  An  interface  between  GDSS  and  the  GTN  prototype  already  exists. 
It  will  also  be  included  in  the  GTN  initial  operating  capability. 

♦  ICS.  The  schedule  for  completing  an  interface  between  the  Integrated  Com¬ 
mand,  Control,  and  Commmiications  System  (ICS)  and  GTN  depends  on 
when  the  ICS  is  completed. 

♦  DAAS.  An  interface  between  the  Defense  Automated  Addressing  System 
(DAAS)  and  the  GTN  prototype  already  exists.  It  will  also  be  included  in 
the  GTN  initial  operating  capability. 

♦  PRAMS.  An  interface  between  the  Passenger  Reservation  and  Manifesting 
System  (PRAMS)  and  the  GTN  prototype  already  exists.  It  also  be  included 
in  the  GTN  initial  operating  capability. 


Other  System  Interfaces 

Figure  C-4  shows  the  schedule  for  10  additional  system  interfaces  that  are 
required  before  the  DoD  can  have  a  comprehensive  ITV  system.  Three  assump¬ 
tions  were  used  in  establishing  the  timelines  for  those  interfaces.  First,  the  work¬ 
loads  for  each  system  program  office  have  been  leveled  so  that  no  more  than 
three  interfaces  occur  simultaneously.  Second,  the  timelines  for  developing  the 
interfaces  have  been  cross  referenced  to  the  implementation  activities  identified 
in  Chapter  4  to  ensure  that  all  activities  occur  in  the  proper  sequence.  Third,  like 
GTN,  each  interface  will  require  one  year  to  implement.  Figure  C-5  shows  a 
likely  set  of  activities  and  a  timetable  for  accomplishing  each  interface. 
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System 

Schedule® 

1994 

1995 

1996 

1997 

1998 

1999 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

Jul 

Jan 

WPS  -  theater  system 

■ 

CAPS  II  -  theater  system 

Commercial  foreign  carriers  -  theater  system 

TC  AIMS -CAPS  II 

TC  AIMS  -  CFM 

TCAIMS-  WPS 

TC  AIMS -TC  AIMS 

PRAMS  -  sen/ice  personnel  systems 

■■■■ 

■■■■ 

PRAMS  -  commercial  resenrations  systems 

PRAMS -TRAC2ES 

'Month  in  schedule  columns  indicates  a  six-month  period  beginning  with  that  month. 


Figure  C-4, 

Other  irV  System  Interfaces 


Task 

Month 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

Identify  operating  concept 

Detail  data  requirements 

mi 

Identify  hardware/software  specifications 

— 

Identify  communications  strategy 

Develop  interface  requirements 
specifications 

Develop  interface  programs 

Install  hardware  and  software 

f  1  ■ 

' 

Arrange  for  communications 

mm^ 

^■■lllll 

III1I....U.U 

Test,  evaluate,  and  modify  interface 

Twmm 

Implement  interface 

Figure  C-5. 

Typical  Interface  Timetable 
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Enhance  Source  Data 


Table  C-1  identifies  nine  opportunities  for  improving  the  access  to  ITV  data. 
Many  of  those  opportunities  call  for  the  use  of  EDI  techniques  to  transmit  data 
from  a  DoD  or  commercial  source  (usually  in  CONUS)  to  an  intermediate  data 
base.  The  detailed  implementation  plans  for  capitalizing  upon  these  opportuni¬ 
ties  follow. 


Implement  EDI  Capability  at  Defense  Ordnance  Shipping  Activities 

The  CFM  Field  Module  is  currently  testing  the  transmission  of  EDI- 
formatted  shipment  information  to  DTTS.  Although  the  Army's  Standard  Depot 
System  (SDS)  intends  to  field  an  automated  GBL  preparation  system  using  EDI 
techniques  in  March  1995,  it  cannot  satisfy  DTTS  data  requirements  without  ad¬ 
ditional  funding.  When  fully  operational,  the  CFM  Field  Module  and  other 
automated  GBL  systems  are  expected  to  process  approximately  44,000  of  an  esti¬ 
mated  55,000  ordnance  shipments  each  year.  (The  other  ordnance  shipments  are 
addressed  in  the  non-EDI  capable  shipping  activities  task.) 

In  the  operating  concept  for  EDI-capable  ordnance  shipping  activities,  the 
data  are  formatted  using  the  ASC  X12  858  Transaction  Sets  and  transmitted  to 
the  CFM  system  for  rating  and  routing  imder  the  Defense  transportation  elec¬ 
tronic  data  interchange  (DTEDI)  program.  The  implementation  plan  for  GBL 
shipments  (Figure  C-8  on  page  C-25)  provides  a  detailed  schedule  for  achieving 
ITV  over  these  types  of  shipments. 


Capture  Ordnance  Data  from  Non-EDI  Shipping  Activities;  Expand 
DTTS  to  Other  Modes 

This  task  addresses  the  methods  and  procedures  required  for  DTTS  to  re¬ 
ceive  ordnance  shipment  information,  to  include  individual  transportation  con¬ 
trol  numbers  (TCNs),  from  non-EDI  capable  CONUS  and  OCONUS  shipping 
activities.  Table  C-4  lists  the  tasks  for  developing  the  methods  and  procedures  at 
non-EDI  capable  shipping  activities  and  for  expanding  DTTS  mode  surveillance 
m  CONUS  and  OCONUS. 
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Table  C-4. 

Implementation  Plan  —  Non-EDI  Shipping  Activities  Ordnance  Data 
Capture  and  DTTS  Mode  Expansion 

1 .0  Finalize  functional  requirements 

1.1  Finalize  operating  concepts 

1 .2  Finalize  data  requirements 
2.0  Specify  operating  requirements 

2.1  Define  system  interfaces 

2.2  Establish  telecommunications  strategy 

2.3  Identify  shipping  activity  and  DTTS  system  modifications 

2.4  Assess  hardware  and  software  requirements 

2.5  Identify  facility  and  personnel  requirements 
3.0  Integrate  and  test  system 

3.1  Procure  required  facility  additions  and  employ  personnel 

3.2  Procure  and  install  hardware  and  software 

3.3  Modify  applications  systems 

3.4  Develop  system  interfaces 

3.5  Arrange  for  telecommunications 

3.6  Update  operating  procedures 

3.7  Train  operators 

3.8  Test,  evaluate,  and  modify  system 
4.0  Field  system 


1.0  Finalize  Functional  REQuntEMENTS 

A  project  team  comprised  of  USTRANSCOM,  DTTS,  Military  Services, 
MTMC,  and  DLA  representatives  will  finalize  the  operating  concept  and  detail 
the  data  requirements. 


1.1  Finalize  Operating  Concepts 

The  project  team  will  review  and  finalize  the  operating  concept  for  captur¬ 
ing  ordnance  shipment  information  from  non-EDI  capable  shipping  activities, 
CONUS  ran  and  ocean  carriers,  and  OCONUS  motor,  rail,  and  ocean  carriers. 
Each  operating  concept  must  address  the  DTTS  monitoring  of  aH  shipments. 


1.2  Finalize  Data  Requirements 

The  project  team  will  identify  and  document  the  data  requirements  needed 
to  support  the  operational  requirements  identified  in  Subtask  1.1.  It  will  also 
identify  the  data  and  transmission  timing  requirements  for  monitoring  the 
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additional  carriers  associated  with  expanding  system  capability  to  other  modes 
and  to  OCONUS  shipments. 


2.0  Specify  Operating  Requirements 

After  developing  the  functional  requirements,  the  project  team  wUl  define 
the  system  interfaces,  identify  the  telecommimications  requirements,  determine 
application  system  modifications,  and  assess  additional  software  requirements  to 
accommodate  the  operating  concepts  finalized  in  Subtask  1.1. 


2.1.  Define  System  Interfaces 

The  project  team  will  identify  and  define  the  system  interfaces  required  by 
DTTS  to  satisfy  both  operating  concepts. 


2.2  Establish  Telecommunications  Strategy 

The  project  team  will  formulate  a  communications  strategy  for  receiving 
shipment  information  electronically  from  non-EDI  capable  shipping  activities 
and  for  expanding  DTTS  to  support  other  modes  of  transportation.  It  will  also 
identify  the  resources  required  to  implement  those  strategies. 


2.3  Identify  Shipping  Activity  and  DTTS  System  Modifications 

The  project  team  will  determine  the  system  modifications  needed  in  the 
shipping  activity  source  systems  and  DTTS  to  accommodate  the  non-EDI  ship¬ 
ping  activities  and  DTTS  mode  expansion. 

2.4  Assess  Hardware  and  Software  Requirements 

The  project  team  will  assess  the  existing  shipping  activity's  systems  to  deter¬ 
mine  if  any  additional  hardware  and  software  are  required  to  support  the  non- 
EDI  shipping  activities,  mode  expansion,  and  DTTS  central  computer  hardware 
and  software  to  support  those  requirements. 


2.5  Identify  Facility  and  Personnel  Requirements 

The  project  team  will  identify  any  additional  facility  and  personnel 
requirements. 
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3.0  Integrate  AND  Test  System 


The  project  team  will  oversee  the  development,  procurement,  integration, 
and  testing  of  hardware,  software,  telecommunications,  and  facilities.  It  will  also 
update  all  operating  procedures  and  train  system  operators. 

3.1  Procure  Required  Facility  Additions  and  Employ  Personnel 

The  project  team  will  oversee  the  procurement  of  additional  facilities,  if  any, 
and  the  hiring  of  required  personnel,  as  identified  in  Subtask  2.5. 

3.2  Procure  and  Install  Hardware  and  Software 

The  project  team  will  coordinate  the  procurement  and  installation  of  the 
hardware  and  software  needed  to  support  the  proposed  operating  concepts. 

3.3  Modify  Applications  Systems 

The  project  team  will  ensure  that  the  system  enhancements  identified  in 
Subtask  2.3  are  developed  in  a  timely  and  coordinated  manner. 

3.4  Develop  System  Interfaces 

The  project  team  will  monitor  development  of  the  system  interfaces  defined 
in  Subtask  2.1. 


3.5  Arrange  for  Telecommunications 

The  project  team  will  arrange  for  the  telecommunications  services  identifies 
in  Subtask  2.2  at  all  source  shipping  activity  locations  and  DTTS. 

3.6  Update  Operating  Procedures 

The  project  team  wiU  ensure  that  DTTS  personnel  update  the  operating  pro¬ 
cedures  consistent  with  the  new  operating  concepts.  Those  procedures  should 
address  software  operations,  transmission  times,  customer  service  levels,  backup 
routines,  and  business  procedures. 

3.7  Train  Operators 

The  project  team  will  formulate  and  oversee  a  comprehensive  training  pro¬ 
gram  that  includes  basis  communications  and  operating  concepts  and 
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responsibilities  for  ensuring  the  timely  and  accurate  transmission  of  ordnance 
shipment  data. 


3.S  Test,  Evaluate,  and  Modify  System 

The  project  team  will  evaluate  and  modify,  as  appropriate,  all  components 
of  the  entire  system  —  telecommimications,  hardware,  software,  interface  pro¬ 
grams,  and  applications  systems. 


4.0  Field  System 


Upon  completion  of  testing,  the  project  team  will  coordinate  the  transition  of 
the  operating  concept  to  a  production  environment. 


Implementation  Schedule 

Figure  C-6  shows  the  schedule  for  capturing  ordnance  data  from  non-EDI 
shipping  activities;  and  expanding  DTTS  surveillance  to  CONUS  rail  and  ocean 
carriers,  and  OCONUS  motor,  rail,  and  ocean  carriers. 


Major  activity 

Lead  agent 

Schedule 

1994 

1995 

1996 

1997 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

Jan 

Jul 

1.0  Finalize  functional 
requirements 

DTTS  PMO 

2.0  Specify  operating 
requirements 

DTTS  PMO 

3.0  Integrate  and  test 
system 

DTTS  PMO 

4.0  Field  system 

DTTS  PMO 

Project  team  leader —  DTTS  Program  Management  Office. 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-6. 

Implementation  Schedule  —  Non-EDI  Shipping  Activities  Ordnance  Data  Capture 
and  DTTS  Mode  Expansion 


Vendor 


This  section  identifies  the  tasks  and  responsible  activities  for  implementing 
the  nV  operating  concept  for  vendor  shipments.  Table  C-5  lists  the  tasks  that 
the  DoD  must  accomplish  to  implement  that  concept.  Those  tasks  are  described 
in  more  detail  below. 
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Table  C-5. 

Vendor  Implementation  Plan 


1.0  Identify  functional  requirements 

1.1  Assess  alternative  operating  concepts 

1.2  Select  best  concept 

1 .3  Detail  data  requirements 

1.4  Identify  and  develop  policy,  regulation,  and  procedural  changes 
2.0  Review  EDI  standards  and  conventions 

2.1  Map  data  requirements  to  ASC  XI 2  858  Transaction  Set 

2.2  Modify  the  ASC  X12  858  Transaction  Set 

2.3  Prepare  data  conventions 

3.0  Specify  technical  operating  requirements 

3.1  Review  and  complete  hardware  specifications 

3.2  Identify  software  requirements 

3.3  Establish  telecommunications  strategy 
4.0  Integrate  and  test  system 

4.1  Procure  and  install  hardware  and  software 

4.2  Modify  application  systems 

4.3  Develop  interface  programs 

4.4  Arrange  for  telecommunications 

4.5  Update  operating  procedures 

4.6  Train  operators 

4.7  Test,  evaluate,  and  modify  system 
5.0  Establish  trading  partner  relationships 

5.1  Develop  trading  partner  implementation  strategy 

5.2  Prepare  and  distribute  trading  partner  information 

5.3  Solicit  trading  partners  and  execute  trading  partner  agreements 
6.0  Implement  production  system 

1.0  IDE^raFY  Functional  Requirements 

In  this  task,  a  project  team  tmder  the  leadership  of  DLA  with  representative 
from  USTRANSCOM,  TCCs,  Military  Services,  and  Defense  Logistics  Manage¬ 
ment  Systems  Office  (DLMSO),  will  review  alternative  operating  concepts;  select 
the  best  concept;  detail  the  data  requirements;  and  identify  and  develop  policy, 
regulation,  and  procedural  changes. 

1.1  Assess  Alternative  Operating  Concepts 

The  project  team  will  review  and  assess  alternative  operating  concepts  for 
capturing  vendor-generated  shipping  information.  In  making  that  review  and 
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assessment,  it  will  work  closely  with  the  procurement  community  and  DLMSO's 
MILSCAP  team  to  assess  the  feasibility  of  each  alternative. 


1.2  Select  Best  Concept 

The  project  team  will  select  the  best  operating  concept,  or  combination  of 
operating  concepts,  and  then  identify  the  DoD  organizations  responsible  for  re¬ 
ceiving  vendor-generated  information. 


1.3  Detail  Data  Requirements 

The  Military  Services  and  DLA  will  identify  and  document  all  vendor¬ 
generated  shipment  information  data  requirements. 


1.4  Identify  and  Develop  Policy,  Regulation,  and  Procedural  Changes 

The  project  team  will  review  current  policies,  regulations,  and  procedures, 
such  as  MILSCAP  and  the  Federal  Acquisition  Regulation  (FAR),  for  purposes  of 
identifying  changes  to  those  documents  that  will  result  in  the  DoD  receiving  the 
required  ITV  information. 


2.0  Review  EDI  Standards  AND  Conventions 

USTRANSCOM  will  map  vendor  data  requirements  into  the  ASCX12 
858  Transaction  Set,  modify  the  ASC  X12  858  Transaction  Set  as  required,  and 
prepare  data  conventions. 


2.1  Map  Data  Requirements  to  ASC  X12  858  Transaction  Set 

In  this  subtask,  USTRANSCOM  maps  the  vendor  data  requirements  (de¬ 
tailed  in  Subtask  1.3)  into  the  ASC  X12  858  Transaction  Set. 


2.2  Modify  the  ASC  X12  858  Transaction  Set 

USTRANSCOM  will  work  with  the  ASC  X12  committee  to  modify  the  ASC 
X12  858  Transaction  Set  to  accommodate  the  new  data  requirements  identified  in 
Subtask  1.3. 


2.3  Prepare  Data  Conventions 

USTRANSCOM  will  enhance  the  DoD  data  conventions  for  the  ASC  X12 
858  Transaction  Set  to  include  new  data  requirements. 
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3.0  Specify  Technical  Operaitng  Requirements 


The  DoD  activities  designated  in  Subtask  1.2  will  identify  the  hardware, 
software,  and  telecommunications  necessary  to  support  the  operating  concept. 


3.1  Review  and  Complete  Hardware  Specifications 

The  designated  activities  will  examine  the  technical  architecture  and  system 
throughput  requirements  to  identify  the  hardware  required  to  support  the  re¬ 
ceipt  of  vendor-generated  EDI  shipment  information. 


3.2  Identify  Software  Requirements 

The  designated  activities  will  determine  the  additional  software  and  appli¬ 
cation  system  modifications  required  to  support  the  planned  operating  concept. 


3.3  Establish  Telecommunications  Strategy 

DLA  and  the  designated  activities  wiU  develop  a  communications  strategy 
for  capturing  vendor-generated  data  electronically. 


4.0  Integrate  AND  Test  System 

DLA  and  the  designated  activities  will  procure  and  install  the  hardware  and 
software,  modify  the  application  systems,  develop  the  interface  programs,  estab¬ 
lish  the  telecommunications  linkages,  update  the  operating  procedures,  train  the 
operators,  and  test  the  system. 


4.1  Procure  and  Install  Hardware  and  Software 

The  designated  activities  will  procure  and  install  the  hardware  and  software 
needed  to  support  the  operating  concept. 


4.2  Modify  Application  Systems 

The  designated  activities  will  modify  their  application  systems  as  identified 
in  Subtask  3.2.  At  a  minimum,  those  modifications  should  include  receiving  and 
processing  vendor-generated  shipment  data  electronically  and  interfacing  those 
systems  with  GTN. 
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4.3  Develop  Interface  Programs 


The  designated  activities  will  develop  a  program  to  pass  vendor-generated 
EDI  data  from  the  EDI  translator  to  an  application  system. 


4.4  Arrange  for  Telecommunications 

The  designated  activities  will  arrange  for  the  telecommunications  capability 
identified  in  Subtask  3.3. 


4.5  Update  Operating  Procedures 

Budding  upon  the  operating  concept  identified  in  Subtask  1.2  and  the  revi¬ 
sions  to  procedures  identified  in  Subtask  1.4,  the  designated  activities  will  for¬ 
mulate  detailed  operating  procedures  for  day-to-day  operations.  Those 
procedures  should  address  software  operation,  transmission  times,  customer- 
service  levels,  backup  routines,  and  business  procedures. 


4.6  Train  Operators 


DLA  and  the  designated  activities  will  formulate  and  oversee  a  comprehen¬ 
sive  training  program  that  includes  an  EDI  overview,  translation  software  opera¬ 
tion,  and  new  operating  procedures  to  ensure  the  timely  and  accurate  receipt  and 
processing  of  vendor-generated  data. 


4.7  Test,  Evaluate,  and  Modify  System 

The  designated  activities  will  field  the  EDI-technical  configuration,  establish 
telecommunications  links,  test  the  system  at  selected  sites,  and  make  any  neces¬ 
sary  system  modifications.  They  should  carry  out  testing  in  two  phases.  First, 
they  should  test  the  system  mtemally  using  sample  data,  evaluate  the  results, 
and  make  appropriate  modifications.  In  the  second  phase,  they  should  test  the 
system  using  real  data  sent  by  a  selected  number  of  vendors.  They  should  then 
evaluate  and  modify,  as  appropriate,  every  component  of  the  entire 
system  —  telecommxinications,  hardware,  translation  software,  interface  pro¬ 
grams,  and  application  systems.  Both  phases  should  be  repeated  until  the  sys¬ 
tem  passes  all  testing  criteria. 


5.0  Establish  Trading  Partner  Relatonships 

Following  successful  system  testing,  DLA  will  formulate  a  strategy  for  solic¬ 
iting  and  working  with  trading  partners  (commercial  vendors  and  carriers.)  The 
strategy  should  include  development  of  an  information  package  and  procedures 
for  encouraging  industry  participation. 
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5.1  Develop  Trading  Partner  Implementation  Strategy 


DLA  will  develop  a  strategy  for  establishing  EDI  capabilities  with  its  indus¬ 
try  trading  partners.  The  strategy  should  address  the  pace  of  implementation, 
milestones,  and  methods  of  operation  for  both  DoD  and  commercial  vendor 
trading  partners. 


5.2  Prepare  and  Distribute  Trading  Partner  Information 

DLA  will  prepare  an  information  package  for  all  prospective  trading  part¬ 
ners.  That  package  should  contain  such  information  as  implementation  proce¬ 
dures,  operating  concepts,  EDI  passwords  and  codes,  points  of  contact,  and  EDI 
trading  partner  agreements.  It  should  also  include  the  implementation  guide¬ 
lines  developed  in  Subtask  2.3. 


5.3  Solicit  Trading  Partners  and  Execute  Trading  Partner  Agreements 

Using  the  products  of  Subtasks  5.1  and  5.2,  DLA  will  solicit  trading  partners 
to  participate  in  its  EDI  program  and  prepare  the  necessary  trading  partner 
agreements. 


6.0  Implement  PRODUcnoN  System 

Once  testing  is  completed  and  all  trading  partners  are  ready  to  receive  and 
send  nV  information  electronically,  the  program  will  move  into  a  production 
environment. 


Implementaiton  Schedule 

Figure  C-7  shows  the  schedule  for  implementing  the  ASC  X12  transaction 
sets  for  receiving  vendor-generated  data.  If  it  adheres  to  this  schedule,  the  DoD 
should  have  a  timely  and  comprehensive  flow  of  vendor-generated  data  to 
GTN. 

Government  Bill  of  Lading 

The  DTEDI  program  is  well  xmderway  toward  replacing  the  GBL  and  other 
routine  freight  and  personal  property  payment  documents  with  electronic  trans¬ 
actions.  With  an  EDI  infrastructure  at  CONUS  shipping  activities,  DoD  will  be 
able  to  capture  much  of  the  CONUS  source  data  needed  for  ITV  by  interfacing 
GTN  with  the  CFM  system. 
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Major  activity 

Lead  agent 

Schedule 

1995 

1996 

1997 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

1.0  Identify  functionai 
requirements 

DLA 

2.0  Review  EDI  standards 
and  conventions 

USTRANSCOM 

3.0  Specify  technical 
operating  requirements 

DLA 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

4.0  Integrate  and  test 
system 

DLA 

_ 

5.0  Establish  trading 
partner  relationships 

DLA 

_ 

II 

6.0  Implement  production 
system 

DLA 

Project  team  leader —  DLA. 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-7. 

Vendor  Implementation  Schedule 


This  section  presents  an  implementation  plan  for  capturing  GBL  data  at 
CONUS  shipping  activities  that  use  the  following  origia  systems:  Cargo  Move¬ 
ments  Operations  System  (CMOS);  CFM  Field  Module;  Transportation  Coordi¬ 
nator's  Automated  Command  and  Control  Information  System  (TC  ACCIS); 
Transportation  Management  System  (TMS);  Defense  Subsistence  Officer  Auto¬ 
mated  Transportation  System  (DSOATS);  Transportation  Automated  Manage¬ 
ment  System  (TRAMS);  Defense  Warehousing  and  Shipping  Procedures 
(DWASP);  Stock  Control  and  Distribution  (SC&D);  Navy  Automated  Transporta¬ 
tion  and  Dociimentation  System  (NAVADS);  Standard  Depot  System  (SDS);  and 
Distribution  Standard  System  (DSS).  Figure  C-8  shows  the  number  of  DoD  ship¬ 
ping  activities  currently  using  each  system  and  the  scheduled  start  and  end  dates 
for  implementing  EDI  at  all  activities.  The  current  status  of  each  system  is  de¬ 
scribed  below. 


CMOS 


The  initial  testing  of  CMOS  began  late  in  calendar  year  1993.  Twelve  activi¬ 
ties  are  now  using  CMOS  to  send  electronic  GBL  information  to  the  CFM  system. 
The  Air  Force  plans  to  have  100  activities  using  CMOS  to  pass  GBL  data  elec¬ 
tronically  to  the  CFM  system  by  the  end  of  calendar  year  1994,  with  another  100 
activities  by  the  end  of  calendar  year  1996. 
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CONUS  origin  system 

Number  of 
activities 

Schedule 

1994 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

CMOS 

200 

^-i 

— — 

— 

CFM  Field  Module 

264 

— 

— 

— 

— 

TC-ACCIS 

42 

- 

TMS 

11 

EDI  implementation  complete 

DSOATS 

22 

(Currently  no  plans  to  field  EDI  capability;  may  get  rolled  into  TRAMS) 

TRAMS 

33 

— 

DWASP 

6 

— 

SC&D 

5 

Legacy  system  (no  EDI  capability  planned) 

NAVADS 

8 

Legacy  system  (no  EDI  capability  planned) 

SDS 

23 

- 

— — 

DSS 

*(30) 

► 

Total 

614 

Legend: 


=  Implementation  has  no  end  date  projected. 


=  Implementation  started  prior  to  calendar  year  1 994. 


*  DSS  activities  already  counted  as  legacy  system  activities  (SDS,  SC&D,  NAVADS,  and  TMS). 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  w/ith  that  month;  DSS  activities  already  counted  as 
other  legacy  system  activities. 


Figure  C-8. 

GBL  Implementation  Schedule 
CFM  Field  Module 

Cxirrently,  over  100  activities  have  completed  testing  and  are  using  the  CFM 
Field  Module.  The  remaining  activities  are  projected  to  be  operational  during 
FY95. 


TCACCIS 

Forty  two  TC  ACCIS  activities  are  schedtiled  to  begin  testing  the  use  of  EDI 
to  transmit  GBL  data  to  the  CFM  system  in  March  1995.  The  completion  date  for 
that  testing  has  not  been  finalized. 


TMS 


The  Marine  Corps  completed  the  fielding  of  TMS  in  November  1990.  That 
system  now  exchanges  ASC  X12  858  Transaction  Set  data  among  Marine  Corps 
Transportation  Management  Offices  (TMOs)  on  a  daily  basis.  The  TMOs  have 
the  capability  to  transmit  and  receive  all  EDI  transactions  with  carriers,  MTMC, 
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other  DoD  consignees,  and  DoD  payment  centers.  However,  they  have  not  es¬ 
tablished  a  connection  to  DoD's  commercial  EDI  value-added  network  (VAN) 
services. 


DSOATS 


DLA  has  no  plans  to  incorporate  an  EDI  capability  into  DSOATS.  However, 
DSOATS  is  being  incorporated  into  TRAMS,  which  has  an  EDI  capability. 


TRAMS 


DLA's  contract  management  activities  began  using  TRAMS  to  send  EDI 
transmissions  of  GBL  data  to  the  CTM  system  in  February  1994.  Those  activities 
will  ultimately  exchange  electronic  data  with  approximately  600  commercial 
vendors  by  the  end  of  FY96. 


DWASP 


DLA's  six  original  depots  began  using  DWASP  to  send  EDI  transmissions  of 
GBL  data  to  the  CFM  system  in  the  middle  of  1994. 


SC&D/NAVADS 


The  SC&D  and  NAVADS  systems  have  no  plans  to  implement  EDI  because 
they  are  legacy  systems. 


SDS 

The  Army  will  begin  testing  the  capability  of  SDS  to  send  GBL  data  elec¬ 
tronically  to  the  CFM  system  at  23  activities  on  24  January  1995.  Although  the 
Army  has  not  yet  established  a  firm  implementation  date  for  SDS  at  those  activi¬ 
ties,  it  is  scheduled  to  field  an  EDI  capability  at  one  of  three  data  processing  cen¬ 
ters,  Chambersburg,  PA,  on  24  March  1995.  Those  centers  are  being  established 
to  service  the  23  activities.  Once  fielding  is  complete  at  the  three  centers,  the  23 
SDS  activities  will  then  become  operational. 


DSS 


DLA  is  replacing  the  distribution  systems  at  its  30  depots  with  DSS.  Some  of 
the  depots  that  currently  use  either  DWASP,  SC&D,  NAVADS,  TMS,  or  SDS  be¬ 
gan  sending  electronic  transmissions  of  GBL  data  to  the  CFM  system  in  1994. 
However,  DLA  has  not  yet  determined  when  DSS  will  be  implemented  at  all  of 
its  depots. 
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Commercial  Bill  of  Lading/Small  Parcel 


As  the  DoD  implements  its  EDI  program  for  capturing  GBL  information,  it 
will  also  be  establishing  an  infrastructure  for  supporting  the  capture  of  CBL  in¬ 
formation  using  EDI  techniques.  Nonetheless,  the  DoD  still  has  a  number  of 
tasks  associated  with  capturing  CBL  and  small  parcel  shipment  information. 
This  plan  identifies  those  tasks  (see  Table  C-6)  and  the  organizations  responsible 
for  accomplishing  them,  and  presents  an  implementation  schedule.  Each  task  is 
described  in  more  detail  below. 

Table  C-6. 

CBL/Small  Parcel  Implementation  Plan 


1 .0  Develop  functional  requirements 

1.1  Finalize  operating  concept 

1.2  Detail  data  requirements 

1 .3  Identify  and  resolve  business  and  legal  issues 
2.0  Review  EDI  standards  and  conventions 

2.1  Map  data  requirements  to  ASC  XI 2  858Transaction  Set 

2.2  Modify  ASC  XI 2  858  Transaction  Set 

2.3  Prepare  data  conventions 

3.0  Specify  technical  operating  requirements 

3.1  Review  and  complete  hardware  specifications 

3.2  Identify  software  requirements 

3.3  Establish  telecommunications  strategy 
4.0  Integrate  and  test  system 

4.1  Procure  and  install  hardware  and  software 

4.2  Modify  application  systems 

4.3  Develop  interface  programs 

4.4  Arrange  for  telecommunications 

4.5  Update  operating  procedures 

4.6  Train  operators 

4.7  Test,  evaluate,  and  modify  system 
5.0  Implement  production  system 


1.0  Develop  Functional  Requirements 

Under  the  overall  leadership  of  USTRANSCOM,  a  project  team  consisting  of 
representatives  from  USTRANSCOM,  TCCs,  Military  Services,  and  DLA  will  re¬ 
view  and  finalize  the  ITV  operating  concept,  detail  the  data  requirements,  deter¬ 
mine  application  system  modifications  or  develop  a  new  system  to  satisfy  the 
operating  concept  and  data  requirements,  and  identify  and  resolve  any  business 
and  legal  issues. 
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1.1  Finalize  Operating  Concept 


The  project  team  will  review  and  finalize  the  ITV  operating  concept  for  cap¬ 
turing  CBL  and  small  parcel  shipment  information. 


1.2  Detail  Data  Requirements 

The  project  team  will  identify  and  document  the  CBL  and  small  parcel  ship¬ 
ment  information  data  requirements. 


2.3  Identify  and  Resolve  Business  and  Legal  Issues 


The  project  team  will  identify  and  resolve  all  business  and  legal  issues  asso¬ 
ciated  with  implementing  EDI  for  CBL  and  small  parcel  shipments.  These  ac¬ 
tions  will  likely  include  modifying  existing  or  developing  new  Defense 
transportation  and  accounting  procedures. 


2.0  Review  EDI  Standards  AND  Conventions 

USTRANSCOM  will  map  the  CBL  and  small  parcel  data  requirements  to  the 
ASC  X12  858  Transaction  Set,  modify  the  ASC  X12  858  Transaction  Set  to  accom¬ 
modate  CBL  requirements,  and  prepare  data  conventions. 


2.1  Map  Data  Requirements  to  ASC  X12  858  Transaction  Set 

USTRANSCOM  will  map  the  CBL  and  small  parcel  data  requirements  (de¬ 
tailed  in  Subtask  1.2)  into  the  ASC  X12  858  Transaction  Set  following  established 
conventions  for  GBL  data. 


2.2  Modify  ASC  X12  858  Transaction  Set 

USTRANSCOM  will  work  with  the  ASC  X12  committee  to  modify  the  exist¬ 
ing  ASC  X12  858  Transaction  Set  as  required  to  accommodate  any  additional 
data  requirements  identified  in  Subtask  1.2. 


2.3  Prepare  Data  Conventions 

USTRANSCOM  will  expand  the  DoD  data  conventions  for  the  ASC  X12  858 
Transaction  Set  to  include  any  new  CBL  and  small  parcel  data  requirements. 
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3.0  Specify  Techmcal  Operating  Requirements 


The  Military  Service  and  DLA  shipping  activities  wUl  identify  the  hardware, 
software,  and  telecommunications  requirements  to  accommodate  the  operating 
concept  and  data  requirements. 


3.1  Review  and  Complete  Hardware  Specifications 

The  Military  Service  and  DLA  shipping  activities  wiU  examine  the  technical 
architecture  and  expected  system  throughput  to  determine  the  hardware  require¬ 
ments  needed  to  support  the  electronic  processing  of  CBL  and  small  parcel  ship¬ 
ment  information. 


3.2  Identify  Software  Requirements 

The  Military  Service  and  DLA  shipping  activities  will  determine  all  addi¬ 
tional  software  and  application  systems  modifications  required  to  support  the 
electronic  processing  of  CBL  and  small  parcel  shipment  information. 


3.3  Establish  Telecommunications  Strategy 

LFSTRANSCOM  will  develop  a  telecommunications  strategy  to  support  the 
electronic  transmission  of  CBL  and  small  parcel  shipment  data  from  Defense 
shipping  activities  to  MTMC's  CFM  system.  That  strategy  wiU  rely  on  the  tele¬ 
communications  network  used  to  support  GBL  processing.  USTRANSCOM  will 
also  identify  the  resource  requirements  for  expanding  that  network  to  CBL  data. 


4.0  Integrate  AND  Test  System 

The  Military  Service  and  DLA  shipping  activities  will  procure  and  install  the 
necessary  hardware  and  software,  modify  application  systems,  develop  interface 
programs,  establish  telecommunications,  update  operating  procedures,  train  op¬ 
erators,  and  test  the  system. 


4.1  Procure  and  Install  Hardware  and  Software 

The  Military  Service  and  DLA  shipping  activities  wUl  procure  and  install  the 
hardware  and  software  identified  in  Subtasks  3.1  and  3.2. 


4.2  Modify  Application  Systems 

The  MUitary  Service  and  DLA  shipping  activities  wUl  modify  their  applica¬ 
tion  systems  as  identified  in  Subtask  3.2.  At  a  minimum,  those  modifications 
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will  include  the  capability  to  generate  electronic  CBL  and  small  parcel  shipment 
data,  and  other  enhancements  necessary  to  complete  an  interface  between  the 
EDI  translator  and  the  application  system. 


4.3  Develop  Interface  Programs 

The  Military  Service  and  DLA  shipping  activities  will  develop  a  program  to 
pass  CBL  and  small  parcel  EDI  data  from  their  application  system  to  the  EDI 
translator.  The  shippers  should  use  the  existing  program  for  GBL  data,  if 
possible. 


4.4  Arrange  for  Telecommunications 

The  Military  Service  and  DLA  shipping  activities  will  arrange  for  the  tele¬ 
communications  capability  identified  in  Subtask  3.3. 


4.5  Update  Operating  Procedures 

Building  upon  the  operating  concept  finalized  in  Subtask  1.1,  and  using  the 
existing  procedures  for  GBL  shipments.  Defense  shipping  activities  will  formu¬ 
late  detailed  operating  procedures  for  day-to-day  operations.  Those  procedures 
should  address  software  operations,  transmission  times,  customer  service  levels, 
backup  routines,  and  business  procedures. 


4.6  Train  Operators 


The  project  team  will  initiate  the  training  of  system  operators  building  upon 
the  DoD's  experience  in  training  operators  to  support  GBL  processing. 


4.7  Test,  Evaluate,  and  Modify  System 

The  Military  Service  and  DLA  shipping  activities,  and  the  GEM  Program 
Management  Office  will  field  the  EDI  technical  configuration,  establish  telecom¬ 
munications  links,  test  the  system  at  selected  sites,  and  make  any  necessary  sys¬ 
tem  modifications.  All  system  testing  should  be  carried  out  in  two  phases.  First, 
they  should  test  the  system  internally  using  sample  data,  evaluate  the  results, 
and  make  appropriate  modifications.  In  the  second  phase,  they  should  test  the 
system  using  real  data.  Each  component  of  the  entire  system  —  telecommunica¬ 
tions,  hardware,  translation  software,  interface  programs,  and  application 
systems  —  should  be  evaluated  and  modified  as  appropriate.  Both  phases 
should  be  repeated  until  the  system  passes  all  testing  criteria. 
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5.0  Implement  Production  System 


Once  it  has  completed  testing  and  all  system  modifications,  the  program 
will  move  into  a  production  environment. 


Implementaton  Schedule 

Figure  C-9  shows  the  schedule  for  implementing  the  ASC  X12  858  Transac¬ 
tion  Set  for  exchanging  CBL  and  small  parcel  shipment  data.  If  it  adheres  to  this 
schedule,  DoD  should  have  a  timely  and  comprehensive  flow  of  CBL  and  small 
parcel  shipment  information  into  the  CFM  system  and  GTN. 


Major  activity 

Lead  agent 

Schedule 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

1.0  Develop  functional 
requirements 

USTRANSCOM 

2.0  Review  EDI  standards 
and  conventions 

USTRANSCOM 

3.0  Specify  technical 

operating  requirements 

Military  Services,  DLA 

4.0  Integrate  and  test  system 

MTMC,  Military  Services,  DLA 

mmmm 

mammmm 

5.0  Implement  production 
system 

MTMC,  Military  Services,  DLA 

Project  team  leader —  USTRANSCOM. 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-9. 

CBl/Small  Parcel  Implementation  Schedule 


Carrier  Status  Data 

This  section  identifies  the  tasks,  responsible  activities,  and  schedule  for  ex¬ 
panding  the  capability  of  the  CFM  system  and  WPS  to  receive  carrier-generated 
status  messages  electronically.  Table  C-7  lists  the  tasks  associated  with  this  ef¬ 
fort.  Each  task  is  described  in  more  detail  below. 


C-31 


Table  C-7. 

Carrier  Status  Data  Implementation  Plan 


1.0  Finalize  functional  requirements 

1.1  Finalize  operating  concept 

1.2  Detail  data  requirements 
2.0  Migrate  to  EDI  standards 

2.1  Map  data  requirements  to  ASC  XI 2  transaction  sets 

2.2  Modify  ASC  XI 2  transaction  sets 

2.3  Prepare  data  conventions 

3.0  Specify  technical  operating  requirements 

3.1  Identify  hardware  and  software  requirements 

3.2  Establish  telecommunications  strategy 
4.0  Integrate  and  test  system 

4.1  Procure  and  install  hardware  and  software 

4.2  Modify  application  systems 

4.3  Develop  EDI  interface  programs 

4.4  Arrange  for  telecommunications 

4.5  Update  operating  procedures 

4.6  Train  operators 

4.7  Test,  evaluate,  and  modify  system 
5.0  Establish  trading  partner  relationships 

5.1  Develop  trading  partner  implementation  strategy 

5.2  Prepare  and  distribute  trading  partner  information 

5.3  Solicit  trading  partners  and  execute  trading  partner  agreements 
6.0  Implement  production  system 


1.0  Finauee  Functional  Requirement 

Under  the  leadership  of  USTRANSCOM,  a  project  team  consisting  of 
USTRANSCOM,  MTMC,  and  commercial  carrier  representatives  will  finalize  the 
nV  operating  concept  and  detail  the  data  requirements. 


1.1  Finalize  Operating  Concept 

The  project  team  will  review  and  finalize  the  operating  concept  for  receiving 
carrier  status  messages  electronically. 
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1.2  Detail  Data  Requirements 


The  project  team  will  identify  and  document  the  carrier  status  message  data 
requirements. 


2.0  Migrate  TO  EDI  Standards 

USTRANSCOM  will  map  the  carrier  status  data  requirements  to  the  appro¬ 
priate  ASC  X12  transaction  set;  modify  those  standards,  as  required;  and  prepare 
data  conventions. 


2.2  Map  Data  Requirements  to  ASC  X12  Transaction  Sets 

USTRANSCOM  will  map  the  carrier  status  data  requirements  (detailed  in 
Subtask  1.2)  to  the  ASC  X12  214  and  315  Transaction  Sets. 


2.2  Modify  ASC  X12  Transaction  Sets 

USTRANSCOM  will  determine  if  the  ASC  X12  transaction  sets  can  accom¬ 
modate  the  data  requirements  specified  in  Subtask  1.2.  If  not,  USTRANSCOM 
will  work  with  the  ASC  X12  committee  to  modify  the  transaction  sets. 


2.3  Prepare  Data  Conventions 

USTRANSCOM  will  prepare  the  DoD  data  conventions  for  each  of  the  ASC 
X12  transaction  sets. 


3.0  Specify  Technical  Operating  Requirements 

The  project  team  will  identify  the  hardware,  software,  and  telecommunica¬ 
tions  requirements  to  accommodate  the  operating  concept. 


3.2  Identify  Hardware  and  Software  Requirements 

MTMC  will  assess  its  existing  systems  to  determine  any  additional  hard¬ 
ware,  software,  and  application  system  modifications  required  to  support  the  op¬ 
erating  concept. 
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3.2  Establish  Telecommunications  Strategy 


f 


USTRANSCOM  and  MTMC  will  develop  a  strategy  for  receiving  shipment 
status  data  electronically  from  commercial  carriers  and  identify  the  resources  re¬ 
quired  to  implement  the  strategy. 


4.0  Integrate  AND  Test  System 

The  project  team  wUl  procure  and  install  the  EDI  status  message  system,  de¬ 
velop  EDI  interface  programs,  establish  telecommunications  links,  update  oper¬ 
ating  procedures,  train  operators,  test  the  system,  and  make  any  necessary 
system  modifications. 


4.1  Procure  and  Install  Hardware  and  Software 

MTMC  will  procure  and  install  the  hardware  and  software  needed  to  sup¬ 
port  the  operating  concept. 


4.2  Modify  Application  Systems 

MTMC  will  modify  its  application  systems  as  identified  in  Subtask  3.1.  At  a 
minimum,  those  modifications  should  include  the  capability  for  the  CFM  system 
and  WPS  to  receive  and  process  ASC  X12  status  messages. 


4.3  Develop  EDI  Interface  Programs 

MTMC  will  develop  the  interface  programs  that  format  and  pass  status  mes¬ 
sage  data  between  the  CFM  and  WPS  application  systems  and  the  EDI  transla¬ 
tion  software. 


4.4  Arrange  for  Telecommunications 

MTMC  will  arrange  for  the  telecommunications  capability  identified  in 
Subtask  3.2. 


4.5  Update  Operating  Procedures 

Building  upon  the  operating  concepts  developed  in  Subtask  1.1,  MTMC  will 
formulate  detailed  operating  procedures  for  day-to-day  EDI  operations.  Those 
procedures  should  address  software  operations,  transmission  times,  customer 
service  levels,  backup  routines,  and  business  procedures. 
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4.6  Train  Operators 


USTRANSCOM  and  MTMC  will  formulate  and  oversee  a  comprehensive 
training  program  that  includes  an  EDI  overview,  translation  software  operation, 
and  new  operating  procedures  to  ensure  the  timely  and  accurate  transmission  of 
carrier  status  data. 


4.7  Test,  Evaluate,  and  Modify  System 

The  project  team  will  field  the  EDI  technical  configuration,  establish  tele¬ 
communications  links,  test  the  system  at  selected  sites,  and  make  any  necessary 
system  modifications.  The  team  should  carry  out  the  testing  in  two  phases. 
First,  it  should  test  the  system  internally  using  sample  data,  evaluate  the  results, 
and  make  appropriate  modifications.  In  the  second  phase,  the  project  team 
should  test  the  system  using  data  sent  by  a  selected  number  of  commercial  carri¬ 
ers.  Every  component  of  the  entire  system  —  telecommunications,  translation 
software,  interface  programs,  and  applications  systems  —  should  be  exercised  in 
this  phase,  and  then  modified  as  appropriate.  Both  phases  should  be  repeated 
until  the  system  passes  all  testing  criteria. 


5.0  Establish  Trading  Partner  Relationships 

USTRANSCOM  and  MTMC  will  formulate  a  strategy  for  soliciting  and 
working  with  commercial  carrier  trading  partners.  The  strategy  should  include 
development  of  an  information  package  and  procedures  for  encouraging  indus¬ 
try  participation. 


5.1  Develop  Trading  Partner  Implementation  Strategy 

USTRANSCOM  and  MTMC  will  develop  a  strategy  for  establishing  EDI  ca¬ 
pabilities  with  industry  trading  partners.  The  strategy  should  address  the  pace 
of  implementation,  milestones,  and  operating  methods  for  commercial  carrier 
trading  partners. 


5.2  Prepare  and  Distribute  Trading  Partner  Information 

USTRANSCOM  and  MTMC  will  prepare  an  information  package  for  all  pro¬ 
spective  trading  partners.  That  package  should  contain  such  information  as  im¬ 
plementation  procedures,  operating  concepts,  EDI  passwords  and  codes,  points 
of  contact,  and  EDI  trading  partner  agreements.  It  should  also  include  the  imple¬ 
mentation  guidelines  developed  in  Subtask  2.3. 
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5.3  Solicit  Trading  Partners  and  Execute  Trading  Partner  Agreements 

Using  the  products  of  Subtask  5.1  and  5.2,  USTRANSCOM  and  MTMC  will 
solicit  trading  partners  to  participate  in  the  DoD's  EDI  program  and  prepare  the 
necessary  trading  partner  agreements. 


6.0  Implement  Production  System 

Once  it  has  completed  testing  and  system  modifications,  the  program  wiU 
move  into  a  production  environment. 


Implementation  Schedule 

Figure  C-10  shows  the  schedule  for  implementing  the  use  of  ASC  X12  trans¬ 
action  sets  for  exchanging  carrier  status  data. 


Major  activity 

Lead  agent 

Schedule 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

1.0  Finaiize  functional 
requirements 

MTMC 

■ 

■ 

■ 

— 

2.0  Migrate  to  EDI 
standards 

USTRANSCOM 

■ 

■ 

■ 

MM 

3.0  Specify  technical 

operating  requirements 

MTMC 

■ 

■ 

— 

■ 

■ 

4.0  Integrate  and  test 
system 

MTMC 

■ 

■ 

■ 

■ 

5.0  Establish  trading 
partner  relationships 

MTMC 

■ 

■ 

■ 

■ 

6.0  Implement  production 
system 

MTMC 

■ 

■ 

■ 

K 

9 

Project  team  leader —  USTRANSCOM. 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-10. 

Carrier  Status  Implementation  Schedule 


Standard  Automated  Input  Media  Device 

The  SAIMD  includes  the  Army's  Soldier  Readiness  Card  (SRC)  and  the  Mul¬ 
titechnology  Automated  Reader  Card  (MARC).  This  section  presents  a  plan,  in¬ 
cluding  tasks,  responsible  activities,  and  schedules,  for  fielding  the  SAIMDs.  A 
project  team  under  the  leadership  of  the  Joint  Staff  (J-4)  and  consisting  of  Under 
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Secretary  of  Defense  (Personnel  and  Readiness);  Assistant  Secretary  of  Defense 
(Health  Affairs);  Assistant  Secretary  of  Defense  (C^I);  USTRANSCOM;  CINCs; 
and  Military  Service  representatives  will  perform  the  tasks  identified  in 
Table  C-8. 

Table  C-8. 

SAIMD  Implementation  Plan 

1.0  Gather  data 

2.0  Finalize  functional  requirements 

2.1  Finalize  operating  concept 

2.2  Finalize  data  requirements 

2.3  Apply  IDEF  modeling  and  determine  system  modifications 
3.0  Demonstrate  existing  technologies  and  capabilities 

4.0  Test,  evaluate,  and  modify  devices 

4.1  Procure  and  install  hardware  and  software 

4.2  Modify  application  systems  and  develop  interface  programs 

4.3  Test,  evaluate,  and  modify  system 
5.0  Field  system 


1.0  Gather  Data 


The  project  team  will  review  SAIMD  technical  documentation  and  perform  a 
backgroxmd  analysis  and  literature  review. 


2.0  Finalize  Functional  Requirements 

The  project  team  will  finalize  the  operating  concept  and  data  requirements, 
apply  Integrated  Definition  Language  (IDEF)  modeling  and  identify  the  modifi¬ 
cations  that  must  be  applied  to  supporting  systems. 


2.1  Finalize  Operating  Concept 

The  project  team  will  review  and  finalize  the  operating  concept  for  tracking 
personnel/ patients  from  origin  to  destination,  and  ensure  that  the  card  is  usable 
in  both  mature  and  immature  theaters.  The  card  should  be  capable  of  being  read 
by  strategic  and  theater  systems  supporting  ports,  personnel  processing  centers, 
and  medical  treatment  facilities. 
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2.2  Finalize  Data  Requirements 

The  project  team  will  identify  and  document  the  personnel  accoxmtability, 
passenger  manifesting,  and  medical  processing  data  elements  needed  to  accom¬ 
modate  the  operating  concept.  It  will  also  ensure  that  the  users  employ  the  same 
data  elements  for  all  systems  to  provide  a  seamless  interface. 


2.3  Apply  IDEF  Modeling  and  Determine  System  Modifications 

The  project  team  will  apply  IDEF  modeling  to  each  functional  area  and  de¬ 
termine  the  system  modifications  necessary  to  accommodate  the  operating  con¬ 
cept  and  data  requirements  specified  in  Subtasks  2.1  and  2.2. 


3.0  Demonstrate  Existing  Technologies  AND  Capabilities 

The  project  team  will  coordinate  and  oversee  the  demonstrations  of  existing 
SAIMD  technology  to  personnel  and  patient  processing,  and  to  passenger  mani¬ 
festing.  It  will  also  select  the  system  hardware  and  software  for  use  in  the  thea¬ 
ter  proof-of-concept  test. 


4.0  Test,  Evaluate,  AND  Modify  Devices 

The  project  team  will  oversee  the  procurement,  modification,  development, 
testing,  and  integration  of  SAIMD  devices  at  selected  test  sites. 


4.1  Procure  and  Install  Hardware  and  Software 

The  project  team  will  ensure  that  the  hardware  and  software  identified  in 
Task  3.0  are  procured  and  installed  at  test  locations. 


4.2  Modify  Application  Systems  and  Develop  Interface  Programs 

The  project  team  will  direct  and  ensure  that  all  application  system  modifica¬ 
tions  are  accomplished  in  every  system  that  will  be  using  the  SAIMD.  Those 
modifications  will  include  all  interface  programs  developed  to  pass  personnel, 
passenger  manifest,  and  medical  data  between  the  systems. 


4.3  Test,  Evaluate,  and  Modify  System 

The  project  team  will  coordinate  system  testing  and  system  modifications  at 
selected  sites,  test  the  systems  using  selected  cards  and  readers  containing  stan¬ 
dardized  data  with  emphasis  on  joint  operations,  and  then  test  the  quality  and 
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timeliness  of  data  passed  into  the  personnel,  passenger  manifesting  and  medical 
systems.  Every  component  of  the  system  should  be  exercised  during  those  tests. 

5.0  Field  System 


Upon  completion  of  testing  and  modification,  OSD  will  designate  a  Military 
Service  or  Defense  agency  to  procure  the  hardware  and  field  the  system. 

Implementation  Schedule 

Figure  C-11  shows  the  schedule  for  implementing  the  operating  concept  for 
tracking  personnel,  passenger  manifesting,  and  medical  processing  using  the 
SAIMD. 


Major  activity 

Lead  agent 

Schedule 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

1 .0  Gather  data 

Joint  Staff  J-4 

. . * 

nnrrn 

2.0  Finalize  functional 
requirements 

Joint  Staff  J-4 

3.0  Demonstrate  existing 

technologies  and  capabilities 

Joint  Staff  J-4 

4.0  Test,  evaluate,  and  modify  devices 

Joint  Staff  J-4 

MiJIlllM 

HIMIH 

5.0  Field  system 

Joint  Staff  J-4 

— 

Project  team  leader —  Joint  Staff  (J-4). 

Note:  Month  in  schedule  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-11. 

SAIMD  Implementation  Schedule 


MILSTAMP 


This  implementation  plan  identifies  the  tasks,  responsible  activities,  and 
schedules  for  enhancing  MILSTAMP  to  meet  ITV  requirements.  Table  C-9  lists 
the  tasks  associated  with  that  effort.  Each  task  is  described  in  more  detail  below. 
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Table  C-9. 

MILSTAMP  Implementation  Plan 


1 .0  Finalize  functional  requirements 

1.1  Finalize  operating  concept 

1.2  Detail  data  requirements 
2.0  Migrate  to  EDI  standards 

2.1  Map  MILSTAMP  and  ITV  data  requirements  to  ASC  X12  858  Transaction  Set 

2.2  Modify  ASC  XI 2  858  Transaction  Set 

2.3  Prepare  data  conventions 

3.0  Specify  technical  operating  requirements 

3.1  Identify  hardware  and  software  requirements 

3.2  Establish  communications  strategy 
4.0  Integrate  and  test  systems 

4.1  Procure  and  install  hardware  and  software 

4.2  Modify  application  systems 

4.3  Develop  EDI  interface  programs 

4.4  Arrange  for  telecommunications 

4.5  Update  operating  procedures 

4.6  Train  operators 

4.7  Test,  evaluate,  and  modify  system 
5.0  Modify  TCC  systems  and  GTN  interfaces 
6.0  Implement  production  system 


1 .0  Finalize  Functional  Requirements 

A  project  team  under  USTRANSCOM  leadership  and  comprising  represen¬ 
tatives  from  the  Military  Services;  DLA;  TCCs;  and  Defense  Logistics  Manage¬ 
ment  Systems  Office  (DLMSO)  will  finalize  the  ITV  operating  concept  and  detail 
the  associated  data  requirements. 


1.1  Finalize  Operating  Concept 

The  project  team  will  review  and  finalize  the  operating  concept  for  capturing 
TCMD  data  generated  by  the  Military  Service  and  DLA  systems.  That  operating 
concept  should  use  the  ASC  X12  858  Transaction  Set  to  transmit  source  informa¬ 
tion  currently  not  captured  in  MILSTAMP  to  WPS  and  HOST  for  subsequent  up¬ 
loading  to  GTN. 
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1.2  Detail  Data  Requirements 


The  project  team  will  identify  and  document  the  ITV  data  requirements. 
Currently,  MILSTAMP  does  not  provide  information  about  the  origin  to  port 
segment  of  Defense  shipments. 


2.0  Migrate  TO  EDI  Standards 

DLMSO  and  USTRANSCOM  will  map  the  DoD's  ITV  data  requirements  to 
the  ASC  X12  858  Transaction  Set,  modify  the  ASC  X12  858,  and  prepare  the  re¬ 
quired  data  conventions. 


2.1  Map  MILSTAMP  and  ITV  Data  Requirements  to  ASC  X12  858  Transaction  Set 

DLMSO  and  USTRANSCOM  will  map  the  data  requirements  detailed  in 
Subtask  1.2  into  the  ASC  X12  858  Transaction  Set. 


2.2  Modify  ASC  X12  858  Transaction  Set 

DLMSO  and  USTRANSCOM  will  determine  if  the  ASC  X12  858  Transaction 
Set  can  accommodate  the  data  requirements  specified  in  Subtask  1.2.  If  not,  then 
DLMSO  and  USTRANSCOM  should  work  with  the  ASC  X12  committee  to  mod¬ 
ify  the  858  Transaction  Set. 


2.3  Prepare  Data  Conventions 

DLMSO  and  USTRANSCOM  will  prepare  a  MILSTAMP  data  convention  for 
the  ASC  X12  858  Transaction  Set. 


3.0  Specify  Technical  Operating  Requirements 

Military  Services,  DLA,  and  TCCs  will  identify  the  hardware,  software,  and 
telecommunications  requirements  to  accommodate  the  operating  concept. 


3.1  Identify  Hardware  and  Software  Requirements 

Military  Services,  DLA,  and  TCCs  will  assess  their  systems  to  determine  if 
any  additional  hardware,  software,  or  application  system  modifications  are  re¬ 
quired  to  support  the  operating  concept.  They  will  also  identify  any  resource 
shortfalls. 
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3.2  Establish  Communications  Strategy 


The  project  team  will  develop  a  communications  strategy  for  exchanging 
MILSTAMP  source  data  electronically  with  clearance  authority  and  TCC  sys¬ 
tems. 


4.0  Integrate  AND  Test  Systems 

Military  Services,  DLA,  MTMC,  and  Air  Mobility  Command  (AMC)  will 
field  their  EDI  system;  modify  application  systems;  develop  any  EDI  interface 
programs;  update  procedures;  train  operators;  establish  telecommunications 
links;  and  test,  evaluate,  and  modify  the  system. 


4.1  Procure  and  Install  Hardware  and  Software 

Military  Services,  DLA,  MTMC,  and  AMC  will  procure  and  install  the  hard¬ 
ware  and  software  needed  to  support  the  TTV  operating  concept. 


4.2  Modify  Application  Systems 

Military  Services,  DLA,  MTMC,  and  AMC  will  modify  their  application  sys¬ 
tems  as  identified  in  Subtask  3.1. 


4.3  Develop  EDI  Interface  Programs 

Military  Services,  DLA,  MTMC,  and  AMC  will  develop  the  interface  pro¬ 
grams  that  format  and  pass  data  between  their  application  systems  and  the  EDI 
translation  software. 


4.4  Arrange  for  Telecommunications 

Military  Services,  DLA,  MTMC,  and  AMC  will  arrange  for  the  appropriate 
telecommunications  at  all  locations,  as  called  for  in  Subtask  3.2. 


4.5  Update  Operating  Procedures 

DLMSO  and  USTRANSCOM  will  update  the  current  MILSTAMP  and  other 
transportation  procedures  to  ensure  the  timely,  accurate,  and  complete  transmis¬ 
sion  of  ATCMD  data. 


4.6  Train  Operators 


The  team  will  formulate  and  oversee  a  comprehensive  training  program  that 
addresses  basic  EDI  concepts,  translation  software  operation,  and  local  operating 
procedures. 


4.7  Test,  Evaluate,  and  Modify  System 

The  project  team  will  field  the  EDI  technical  configuration  at  source,  clear¬ 
ance,  and  port  systems;  establish  telecommunications  links;  test  the  system  at  se¬ 
lected  sites;  and  make  any  necessary  system  modifications.  Testing  should  occur 
in  two  phases.  First,  the  team  should  test  the  system  intemally  using  sample 
data,  evaluate  the  results,  and  make  appropriate  modifications.  In  the  second 
phase,  the  team  should  test  the  system  using  data  sent  by  selected  source  activi¬ 
ties.  All  testing  should  be  conducted  in  parallel  with  existing  MILSTAMP  data 
flows.  Each  component  of  the  entire  system  —  telecommunications,  translation 
software,  interface  programs,  and  applications  systems  —  should  be  evaluated 
and  modified  as  appropriate.  Both  phases  should  be  repeated  until  the  system 
passes  all  testing  criteria. 


5 .0  Modify  TCC  Systems  and  GTN  Interfaces 

USTRANSCOM,  MTMC,  and  AMC  will  modify  their  systems  and  GTN  in¬ 
terfaces  to  ensure  timely  and  efficient  information  exchange. 


6.0  Implement  Production  System 

Once  it  has  completed  testing  and  system  modifications,  the  DoD  will  move 
into  a  production  environment. 


Implementation  Schedule 

Figure  C-12  shows  the  schedule  for  capturing  enhanced  MILSTAMP  data.  If 
it  adheres  to  this  schedule,  the  DoD  should  have  a  timely  and  comprehensive 
flow  of  ATCMD  data  from  origin  to  port  to  GTN. 
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Major  activity 

Lead  agent 

Schedule 

1995 

1996 

1997 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

1.0  Finalize  functional 
requirements 

DLMSO 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

2.0  Migrate  to  EDI 
standards 

DLMSO 

3.0  Specify  technical 

operating  requirements 

Military  Senrices,  DLA 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

■ 

4.0  Integrate  and  test 
systems 

Military  Services.  DLA 

■ 

■ 

■ 

■ 

■ 

■ 

5.0  Modify  TCC  systems 
and  GTN  interfaces 

MTMC,  AMC, 
USTRANSCOM 

■ 

■ 

■ 

■ 

6.0  Implement  production 
system 

USTRANSCOM 

Project  team  leader —  USTRANSCOM. 

Note:  Month  in  schedule  column  indicates  a  three-month  period  beginning  with  that  month. 


Figure  C-12. 

MILSTAMP  Implementation  Schedule 


Personal  Property 

As  noted  in  Chapter  4,  EDI  offers  an  additional  opportunity  to  enhance  the 
visibility  currently  enjoyed  by  personal  property  shipments.  Electronic  status 
messages  for  selected  types  or  categories  of  shipments,  when  transmitted  from 
carriers  to  personal  property  shipping  offices  (PPSOs),  could 

♦  enhance  the  level  and  quality  of  service, 

♦  reduce  DoD  and  carrier  costs  associated  with  shipment  tracing,  and 

♦  provide  information  useful  to  property  owners. 

This  section  identifies  the  tasks  that  the  Military  Services,  MTMC,  and  the 
Transportation  Operational  Personal  Property  Standard  System  (TOPS)  project 
manager  must  complete  to  implement  the  shipment  status  reporting  process.  It 
also  proposes  a  schedule  for  the  accomplishment  of  each  task.  Table  C-10  shows 
those  tasks.  They  are  described  in  more  detail  below. 


1 .0  Define  Functional  and  Reporting  Requirements 

In  this  task  a  project  team  lead  by  MTMC,  in  coordination  with  the  Military 
Services,  will  identify  the  types  of  shipments  for  which  carriers  will  be  asked  to 
provide  status  messages.  It  will  also  determine  when  the  status  messages 
should  be  requested,  the  carriers  that  will  be  asked  to  send  messages,  the  fre¬ 
quency  of  messages,  the  required  data  elements,  and  the  message  format. 
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Table  C-10. 

Personal  Property  Implementation  Plan 

1 .0  Define  functional  and  reporting  requirements 

1 .1  Identify  shipments  requiring  status  reports 

1.2  Determine  time  after  pickup  that  reporting  begins 

1.3  Identify  carriers  required  to  report  shipment  status 

1 .4  Determine  frequency  of  messages 

1.5  Identify  data  elements 

1 .6  Prescribe  message  format 
2.0  Define  technical  requirements 

2.1  Determine  hardware,  software,  and  programming  changes 

2.2  Identify  facility  and  personnel  requirements 
3.0  Integrate  and  test  system 

3.1  Procure  and  install  hardware  and  software 

3.2  Modify  applications  systems 

3.3  Develop  interface  programs 

3.4  Update  operating  procedures 

3.5  Train  operators 

3.6  Test,  evaluate,  and  modify  system 

4.0  Document  shipment  status  reporting  requirements 

5.0  Coordinate  proposed  changes 

6.0  Coordinate  reporting  requirements  with  industry 

7.0  Publicize  proposed  changes 

8.0  Publish  changes 


1.1  Identify  Shipments  Requiring  Status  Reports 

The  project  team  will  identify  the  shipments,  by  code  of  service,  that  would 
benefit  most  from  status  messages.  In  identifying  those  shipments,  it  should 
consider  status  messages  for: 

♦  All  surface  international  shipments  provided  upon  PPSO  inquiry  (interna¬ 
tional  shipments  transit  the  most  nodes  and  require  the  most  handling, 
thereby  providing  increased  opportunities  for  loss,  damage,  delays,  and 
misroutings). 

♦  All  Blue  Bark  shipments  provided  automatically;  PPSOs  should  not  first 
transmit  an  inquiry. 
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1.2  Determine  Time  after  Pickup  that  Reporting  Begins 
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The  project  team  will  determine  when  shipment  status  updates  are  most 
beneficial.  It  should  consider  requiring  status  messages  on  selected  international 
shipments  upon  request  from  a  PPSO  when 

♦  ocean  transport  commences, 

♦  ocean  transport  is  completed,  and 

♦  the  shipment  has  not  been  or  cannot  be  delivered  by  the  required  delivery 
date  (RDD). 

Carriers  should  automatically  transmit  Blue  Bark  shipment  status  messages 
to  origin  and  destination  PPSOs  upon  the  occurrence  of  those  same  events  with¬ 
out  prompting  or  inquiry  from  PPSOs. 


1.3  Identify  Carriers  Required  to  Report  Shipment  Status 

The  project  team  will  require  all  EDI-capable  carriers,  and  those  willing  to 
attain  that  capability  in  the  near  term,  to  provide  electronic  shipment  status  mes¬ 
sages.  It  will  further  encourage  those  carriers  not  currently  EDI-capable  to  at¬ 
tain  that  capability.  Until  then,  it  will  require  all  carriers  without  the  capability 
to  send  shipment  status  messages  electronically  to  provide  shipment  status  infor¬ 
mation  via  facsimile,  telephone,  or  some  other  means  of  responsive  communica¬ 
tions. 


1.4  Determine  Frequency  of  Messages 

The  project  team  will  determine  the  frequency  of  status  reports  on  late  ship¬ 
ments  to  the  destination  PPSO.  Status  reports  should  be  considered  immediately 
after  the  RDD  has  passed  and  every  24  hours  thereafter  rmtil  shipment  delivery. 
Although  the  first  report  for  non-Blue  Bark  shipments  should  be  provided  in  re¬ 
sponse  to  a  PPSO's  request,  the  follow-up  (every  24  hours)  reports  are  provided 
without  further  inquiry  from  a  PPSO. 


1.5  Identify  Data  Elements 

The  project  team  will  identify  the  data  elements  that  are  to  comprise  each 
status  message.  The  project  team  should  consider  three  messages.  The  first 
would  be  sent  when  ocean  transit  begins,  and  the  second  when  ocean  transit 
ends.  The  data  in  those  two  messages  should  consist  of  the  member's  name, 
rank,  social  security  number,  GBL  number,  RDD,  standard  carrier  alpha  code, 
origin  and  destination  government  bill  of  lading  office  code,  code  of  shipment, 
SPOE,  SPOD,  vessel  name,  date  and  time  of  sailing,  and  date  and  time  of  arrival 
at  the  POD.  The  third  message  would  be  sent  when  a  shipment  fails  to  meet  its 
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RDD.  In  that  message  only  the  member's  name,  rank,  social  security  number, 
GBL  number,  original  RDD,  and  anticipated  revised  RDD  need  to  be  provided. 


1.6  Prescribe  Message  Format 

The  project  team  will  select  the  formats  for  the  inquiry  and  status  report 
messages  that  are  acceptable  to  both  carriers  and  PPSOs.  Messages  transmitted 
via  EDI  should  employ  the  ASC  X12  213  Transaction  Set  for  PPSO  inquiries  and 
ASC  X12  214  Transaction  Set  for  carrier  status  reports.  All  non-EDI  messages 
should  also  be  prepared  following  a  standard  format. 

2.0  DEFI^ffiTEa^NICAL  Requirements 

Following  identification  of  the  functional  reporting  requirements,  the  project 
team  will  address  the  hardware,  software,  facility,  and  manpower  requirements. 

2.1  Determine  Hardware,  Software,  and  Programming  Changes 

The  project  team  will  determine,  in  coordination  with  carrier  and  PPSO  rep¬ 
resentatives,  all  hardware,  software,  and  translation  software  changes  or  up¬ 
grades  needed  to  accommodate  PPSO  inquiry  and  carrier  status  messages. 

2.2  Identify  Facility  and  Personnel  Requirements 

The  project  team  will  identify  the  facilities  (such  as  telephone  lines,  electrical 
outlets,  and  office  space)  to  accommodate  all  required  changes  and  upgrades.  It 
will  also  survey  the  carriers  and  PPSOs  to  determine  the  availability  of  persormel 
and  the  training  needed  to  provide  shipment  inquiry  and  status  reporting. 

3.0  Integrate  AND  Test  System 

This  task  involves  all  efforts  related  to  fielding  new,  or  upgrading  existing, 
EDI  capabilities. 

3.1  Procure  and  Install  Hardware  and  Software 

The  project  team  will  coordinate  the  procurement  and  installation  of  the 
hardware  and  software  specified  in  Subtask  2.1. 
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3.2  Modify  Applications  Systems 
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The  project  team  will  oversee  all  enhancements  to  application  systems  to  ac¬ 
commodate  shipment  inquiry  and  status  messages  in  EDI  format,  and  to  make 
maximum  use  of  the  information  provided. 


3.3  Develop  Interface  Programs 

The  project  team  will  define  the  formats  for  passing  inquiry  and  status  mes¬ 
sage  data  between  applications  systems  and  the  EDI  translation  software. 


3.4  Update  Operating  Procedures 

The  project  team  will  formulate  detailed  operating  procedures  for  day-to- 
day  EDI  operations  and  submit  those  procedures  to  the  Military  Services  so  that 
they  can  review  their  internal  operating  procedures  for  manually  processing 
documents.  It  will  also  link  those  procedures  to  the  new  inquiry  and  reporting 
requirement. 


3.5  Train  Operators 


The  project  team  will  formulate  programs  for  training  system  operators  and 
users. 


3.6  Test,  Evaluate,  and  Modify  System 

The  project  team  will  oversee  EDI  system  testing  using  sample  data,  evalu¬ 
ate  the  results,  and  make  appropriate  modifications.  It  will  also  conduct  an  op¬ 
erational  test  using  actual  data  generated  by  a  small  number  of  selected  carriers 
and  PPSOs. 


4.0  D(XIJMentShipmeot  Status  REroRiTNG  Requirements 

The  project  team  will  draft  changes  to  the  Personal  Property  Traffic  Manage¬ 
ment  Regulation  (PPTMR)  and  revise  the  Tender  of  Service  (TOS)  to  incorporate 
the  shipment  inquiry  and  status  reporting  requirement. 


5.0  Coordinate  Proposed  Changes 

The  project  team  will  coordinate  the  proposed  PPTMR  and  TOS  changes 
with  the  Military  Services  and  present  them  to  the  Personal  Property  Coordinat¬ 
ing  CotmcU. 
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6.0  Coordinate  Reporting  Requirements  with  Industry 


The  project  tecim  will  disseminate  the  proposed  PPTMR  and  TOS  changes  to 
industry  associations  and  carriers,  soliciting  their  comments  and  views.  It  wUl 
also  present  the  concept  and  supporting  documents  to  industry  representatives 
at  a  Military/ Industry  Personal  Property  Symposium,  and  amend  the  proposed 
PPTMR  and  TOS  changes  as  agreed  by  both  DoD  and  industry. 


7.0  Pubucize  Proposed  Changes 

The  project  team  will  submit  the  proposed  changes  to  the  Commerce  Busi¬ 
ness  Daily  for  publication  and  edit  the  changes  in  accordance  with  the  com¬ 
ments  received. 


8.0  Publish  Changes 

Following  the  completion  of  all  testing  and  coordination,  the  project  team 
will  ensure  that  the  PPTMR  and  the  TOS  changes  are  published. 


Implementation  Schedule 

Figure  C-13  shows  the  schedule  for  implementing  personal  property  ship¬ 
ment  status  messages. 


Major  activity 

Lead  agent 

Schedule 

1995 

1996 

Jan 

Apr 

Jul 

Oct 

Jan 

Apr 

1.0  Define  functional  and 
reporting  requirements 

MTMC,  Military  Senrices 

— 

■ 

m 

■ 

2.0  Define  technical 
requirements 

MTMC,  Miiitary  Services 

— 

3.0  Integrate  and  test 
system 

MTMC,  TOPS  project 
manager 

— 

- 

4.0  Document  shipment 

status  reporting  requirements 

MTMC 

E 

m 

■ 

5.0  Coordinate  proposed 
changes 

MTMC 

9 

■ 

6.0  Coordinate  reporting 
requirements  with  industry 

MTMC,  Military/Industry 
Personal  Property 
Symposium 

■ 

■ 

■ 

e 

9 

1 

7.0  Publicize  proposed 
changes 

MTMC 

— 

8.0  Publish  changes 

MTMC,  Military  Services 

— 

Project  team  leader —  MTMC. 


Figure  C-13. 

Personal  Property  Shipment  Status  Messages  —  Implementation 
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